[Pmwiki-users] Internationalization structure

[Patrick R. Michaud]

On Sun, Aug 03, 2003 at 10:34:32PM +0200, Ruediger Marwein wrote:
> Yes, it makes it easy to add internationalization to PmWiki in the standard 
> installation... but with several local-files and modules from the cookbook 
> it's pretty hard to keep it internationalized.
> For my projects including internationalization I always use tags for the text 
> to be displayed in a defined language. Such as i18n:SearchWiki which gets 
> replaced during parsing of the page.

Indeed.  However, I have a couple of conflicting priorities here, because
I think it's equally important to make customization in general understandable
even to those who aren't familiar with i18n issues and requirements.
I'm afraid that introducing a notation such as i18n:SearchWiki could
quickly spread itself throughout the codebase such that relatively new
PHP programmers cannot easily read or customize PmWiki without 
understanding how the language arrays work (cf. PmWikiPhilosophy #5).

> So the data structure would look like:
> tagname[language][country] = text
> for country i use "default" and e.g. "austria" for a differing text to the 
> default german. This reflects the "de_DE"-like notation.

Easier would be tagname["de_DE"] and tagname["de_AT"], which maintains
compatibility with standard language codes but doesn't provide any real
loss of generality.  

> What do you think?

I think it's a very worthy idea but I haven't found the appropriate mechanism
yet (for some reason I'm intuitively biased against using the arrays,
even though I know that's the way it's normally done).  Overall I'm not
sure how easy it is to simultaneously achieve all of the following--
  - completely decouple the text translations from the HTML
  - make it easy for non-expert PHP programmers to create/read/understand 
    custom modules in the Cookbook
  - have it work with all possible customizations

Anyway, the i18n stuff is still a first-cut at solving the problem, so
let's just continue plugging away at it and see what better solutions arise.

Pm