Re: [Phpwiki-talk] internationalisation for phpwiki (fwd)

[Arno H. <aho...@in...>]

>I think having more sets of default pages, in other languages, would be a
>Good Thing. The question though is how to include them in the distro... I
>already told this gentleman that we'd love a set of Dutch pages.

I had a short look at Jan's patch.
Overall it seems ok and looks like a sensible patch.
It seems clear that there are three different things to translate:
	- the pages
	- the templates
	- the code

The first two items pose no problem - one can easily switch by setting
the apropriate directories in wiki_config (or even doing it on the fly, once 
user identification is added).

Translating the code (more precisely: user messages emitted by code) poses 
more of a problem. Jan uses Gnu's gettext. While this seems to be the right 
choice within PHP, I question if it's apropriate for phpwiki.

For example, on my vanilla install of SuSE linux, gettext is not compiled 
into PHP, thus I'd only be able to use the english default. Furthermore,
if I understand the patch correctly, one has to run translate.sh before
starting the wiki. While xgettext and msgfmt are installed on my system, 
msgmerge is not. (We can get around that by adding the output
of translate.sh into the distribution tarball.)

So what I'm complaining about is that this goes somewhat against the 
simplistic approach otherwise taken within phpwiki. I had already one user 
email me that he couldn't set up phpwiki+mysql, because he commented out the 
dbmlib part, but didn't uncomment the mysql section (he didn't recognize that 
"/*" & "*/" are comment delimiters). That's our audience.

Why not use php-files that just include a hash of translated strings?
Ok, it causes some additional work on our side, but not that much. The actual 
changes within the code would then look just like Jan's changes.

I know that gettext simplifies and automates this task. But from my 
POV it would be a bonus not to rely on yet another php module.

/Arno