Re: Localization, Internationalization, Multilanguatisation
Jean-Christophe Michel <jc.michel-/aRvmaKoZxNWk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.lib.binarycloud.devel |
|---|---|
| Message-ID | <[email protected]> |
Wim Niemans ri wrote:
> On 25 Feb 2005 at 1:29, Jean-Christophe Michel wrote:
>
>>If conf is long to load all values, conf should be cached.
>
> Yes. You mean conf.php or the conf_values?
Conf values.
>>Since lang strings will always change slower than php/tpl/ndf files will
>>be used, files with lang strings replaced should be cached. This is the
>>case with our current phing-time localization. I propose to keep this
>>behaviour but wait till someone asks for a page to rebuild it.
>
> First. Convince yourself that momentarily only error messages needs
> translation. They happen to display once a month, I guess.
Testsite is not a real app. Here on a four language site I have forms,
and form labels and required message make a bunch of strings that are
used. If no wiki system is used for contents, you can have thousands of
strings too.
> You favour caching (and using filemtime() 3000 times an hour) in order to
> have these messages display faster? We are talking about very few real messages here.
> (exagerating makes it more clear ;-))
I think your evaluation is wrong.
And I don't propose to use filemtime in production :-)
> Second. Some vietnamees visits your site. The language is not available.
> You set the language to default french, I guess. How do you cache, as
> being french or as vietnamees?
Lang is not country. These are two different things. (By the way that's
why I refuse to use country flags for lang links)
> Third. My workspace application does it's own translation. It supports
> vietnamees. But not for binarycloud core using string files.
> How would you cache that one? Being french or vietnamees?
Like now. If you add vt to your build languages you'll obtain a core
tree in vietnamees, this means, probably messages will be in English
till someone translates them. Same with the cache: there'll be a cache
per language.
> It will become complicated. I've seen software that does an install for a
> language. That install does read the complete translated_strings_thing,
> finds the php_files using the strings and creates specific translation
> files for these php_files individually.
> A variation of this would be: find the php_files which uses the strings,
> insert defines for them in all these files and caches them.
My solution is simpler: convert a file if necessary when it's included.
include_php(path):
if conf/include_php/check_cache
filemtime(path)
if changed
replace strings in file (path)
store it in cache
else
serve cached file
else
if cache file exists
serve cached file
else
replace strings in file (path)
store it in cache
In prod conf/include_php/check_cache will be set to false.
If you change a string you'll either rebuild at home and sync your prod
dir, or delete the cached php files to have them rebuilt.
--
Jean-Christophe Michel