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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.