Multilingual Support/Snippet Installation

Issue #2 is yet to be decided. Got any suggestions?

Hm, the question is
- do we want more lingual version of one document (=1 docid, more content fields), OR
- do we want to have different documents, each one for a seperate language (multiple docids, one content field, language flag; how are they linked together?)


I guess the first case is easy, but I'm not sure if flexible enough:
- The user has to decide upon installation how many different language his content has to support.
- The installer would then create appropiate database tables, so we don't have a not only content field now (for the default language) but also additional content fields (content_fr, content_de, content_3, content_4)
- in manager/document edit/generic you don't have only one content field to edit but all your languages (css layers + tabs to hide/show) so you can simultanously edit all your languages; also it will be required to have pagetitle, description... for each language
- API routines either decide which language to retrieve (based on cookies, browser settings,...) or by a passed parameter; this means - when browsing the content page the parser will replace [*content*] with the appropiate language and event he menu is generated for the appropiate menu


The second case is definitly more flexible as you can add new languages on the fly but if affects a lot of things (site search, menu generation)... also you've got to link together all id's to switch languages on a single specific page... sounds very complicated

Ok, I'm hereby designating myself Asker of the Dumb Questions. ;-)

I know it's already been asked before, but why *wouldn't* we use gettext?

There is a cool intro here on gettext with PHP and websites here:
http://www.onlamp.com/pub/a/php/2002/06/13/php.html

Wordpress even has a module that implements basic gettext without underlying system support that we could borrow from:
http://www.cenamayo.com/wpxref/nav.html?wp-includes/gettext.php.html

I see lots of value in an approach like this. For one, it will auto deal with the differences in number formatting, it will produce blank files ready for translating, it implements the file approach already mentioned, it has wide acceptance already with translation tools in place and a huge community of people already using it.

More information here:
http://www.aota.net/forums/showthread.php?threadid=10615

I only speak English, so I'm mostly just asking Really Dumb Questions, but if anyone does have thoughts on this, I'd be interested just for my own future reference.

I'm interested in translating to Spanish. I have experience maintaining the translation of a Open Source software called Shareaza.

One of the best ways would be to include XML files that have the translations. So when you add an snippet, you simply add another XML file that has that snippet translations. It would be need an special style for develop snippets, plugins, though.

Some things to remember:

Not all languages use the SVO format for grammer. Japanese uses V at times OV. So let's make sure we can translate to 99% of the langagues out there.

Becareful of language flooding -- oscommerce is innudated with oodles of the same phrases but marked differently. I spent the greater part of 40 hours trying to clean up that mess. What a waste of time.

A common dictionary of used phrases should be maintained so that each developer can reference them without the temptation to come up with their own.

Each snippet / plugin should be responsible for keeping the language bits to a bare minimum. This way translators will not have to worry about excesive translation duties.

The code should not be English based. Yes, my mother tongue is English but why should others have to have this forced down their throats?

Can we use variables instead of standard English bits?

I would love to see language control surpass that of postnuke. Not all countries use the same type of boxes (ughh.... osC'er here ... hmmm, those bits of information in boxes to the left and right of most sites).

hmmm ... any other pet peeves?

AHHH, yes! Let's split this topic into easily commentable threads

I know it's already been asked before, but why *wouldn't* we use gettext?

I think there are at least two drawbacks with gettext:

- you add an additional requirement to the modules with have to be avaible to/compiled in PHP

- you need to compile those .po/.mo files in order to use them which might get a bit complicated to do AND complicated to maintain... imagine you write a simple snippet which just needs one text line (ie. "current news")... to create an array or some entries in a database table is really easy, and with the proposed XML container even easy to distribute; otherwise a novice coder has to fizz around with an obscure tool like xgettext and the distribution of that simple snippet gets more complicated (more files to distribute/install)

Not all languages use the SVO format for grammer. Japanese uses V at times OV.

Gosh, you're right. For me I just speak German and a little bit of English so we'd need somebody who speeks Japanese, and my guess is you're the one (at last you're living there!) !?

A common dictionary of used phrases should be maintained

An excellent idea!

This would even enable somebody to create an multilingual bit of code even he doesn't speak that language! And keeps things clean.

AHHH, yes! Let's split this topic into easily commentable threads

:)
As it seems more people than just me are interested in multilingual features maybe we should create a Development>Language forum?

I think there are at least two drawbacks with gettext:

- you add an additional requirement to the modules with have to be avaible to/compiled in PHP

Not necessarily true:

Wordpress even has a module that implements basic gettext without underlying system support that we could borrow from:
http://www.cenamayo.com/wpxref/nav.html?wp-includes/gettext.php.html

- you need to compile those .po/.mo files in order to use them which might get a bit complicated to do AND complicated to maintain... imagine you write a simple snippet which just needs one text line (ie. "current news")... to create an array or some entries in a database table is really easy, and with the proposed XML container even easy to distribute; otherwise a novice coder has to fizz around with an obscure tool like xgettext and the distribution of that simple snippet gets more complicated (more files to distribute/install)

That is probably a worthwhile criticism. The one counterpoint I could come up with, though, might be that gettext seems to becoming the standard for providing internationalization (as opposed to mere translation).

I freely admit to being utterly clueless on this subject, though, so I'm mostly in this thread to learn. (Therefore, any thoughts I have are worth even less than the normal cent and a half at which I value them. )

gettext seems to worth reading more up on but I still can't get the English-centric taste out of my mouth.

I like the idea of a lib of phrases and possibly just using using defines and cacheing the stuff through the db.

That way there is still a interface to edit the files and if one person doesn't like the word color then can change it to colour whenever they feel like it.

@Japan
Yep, I'm white bread but I do speak the talk and have learned to walk the walk a bit. Still I stick out like a thumb but hehe it's still fun.

My parents are German though Mother being half Danish and half East German. My dad is 100%. hehe, lolo Probably Polish too if you figure border movements in :roll:

Been too long in SonyLand so my Spanish and German have gone down the drain ops:

Anway, should get back to code chatting

The one counterpoint I could come up with, though, might be that gettext seems to becoming the standard for providing internationalization (as opposed to mere translation).

I agree on that, however I still don't think it's the easiest thing to use.

Do you think those .po/.mo files could be created "on the fly"?? If yes we could recompile those files after a snippet/plugin installation so we would profit from both the flexibilty from simple install files and a standard interface gettext on the coders side...

I agree on that, however I still don't think it's the easiest thing to use.

Do you think those .po/.mo files could be created "on the fly"?? If yes we could recompile those files after a snippet/plugin installation so we would profit from both the flexibilty from simple install files and a standard interface gettext on the coders side...

Yes, actually, I may have a way.

If we had a function for a translation register mechanism, the translations could store all the strings in a table, either in the DB or the filesystem, during the snippet/plugin install. It would then be fairly trivial to build something into the system to import/export the actual .po/.mo files.

During runtime, the actual translations would be handled by the .po/.mo files using the gettext functionality.

From the programmer's perspective, nothing more than using the translation API would be necessary.

Is that making any sense?