Multilingual Support/Snippet Installation

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[reportra]

The language support is somewhat inflexible now, it's ok for translation of the manager interface but in case of snippets/plugins/modules it's nearly impossible to maintain them. ATM I'm translating the snippets manually.

If language strings are stored in the DB a generic interface could be used to modify/add/delete these.

ie:
modul/snippet/plugin | string_id | lang | string_translated
modx_manager | 1234 | EN | Welcome to MODx
modx_manager | 1234 | DE | Willkommen bei MODx
snippet_newlist | 4567 | DE | Aktuelle Nachrichten

I just don't know what's best in having translation things: arrays, database or gettext?

For the snippets, these strings could be added (or deleted) on (de-)installation when the snippet would have more parts which are seperated on snippet/plugin/etc installation (cutpaste): i.e. a snippet does not contain the snippet itself but more parts: snippet, installation, deinstallation, documentation...

what do you think?

[sottwell]

I created a multilanguage site, and used text files that were named after the "home" folder's ID for each language (i.e. 1.php for English, 2.php for German, etc), and stored the language selected both in the SESSION variable and in the URL query string.

The layout of the document tree has the "home" pages as folders for each language (in its language) in the root, and each language folder contains the documents in its language.

I created a couple of snippets to set/capture the lang variable based on the ID of the "home" page for the language menu the user selects. Apparently every snippet (such as the contact snippet) that will use it needs to include the language file; I tried just including it in the header of the template with a snippet, as well as in the main class file, but that didn't work.  I had to modify most of the snippets and other code that generated or specified links to include the lang variable in the URL query string.

I was also writing the variable to the SESSION array, and hacked the login/logout scripts to carry it through login errors and logout, but it turned out that I didn't need that for this site.

http://www.bmptrans.ch

I used a simple ListMenu renamed TopMenu for the language menu, and another one renamed SideMenu for the main menus.

And, I paid for the use of Etomite on that site without the links and copyright messages.

[xwisdom]

ie:
modul/snippet/plugin | string_id | lang | string_translated
modx_manager | 1234 | EN | Welcome to MODx
modx_manager | 1234 | DE | Willkommen bei MODx
snippet_newlist | 4567 | DE | Aktuelle Nachrichten

I just don't know what's best in having translation things: arrays, database or gettext?

sounds cool to me.

Maybe we can use something like:
resource_code|resource_name|string_id|lang|string_translated
modx|manager | 1234 | EN | Welcome to MODx
modx|manager | 1234 | DE | Willkommen bei MODx
snip | newlist | latenews | EN | Latest news
snip | newlist | archive | EN | Archive news

These information could be stored inside the database and using APIs to retrieve only the strings needed but using a pure database solution would only make things difficult to edit and to deploy.

To solve this I would like to propose that we use the automatic registration of dictionary files:

Here how it works. You copy the .dic files into a dictionary folder and the system will automatically detect and import the new definitions into the database. That's it! Very simple and very easy to deploy you language files

[OpenGeek]

Ryan, I think this is another great use for TVO...a LanguageDisplay class could allow infinite language instances for each attribute...just an additional thought related to our core discussion.

Sorry if I'm being pushy with this... ;-)

[OpenGeek]

and in conjunction with the .dic files (or possible XML dictionary files? is there a related standard anywhere?), just access to these would be elementary

[xwisdom]

Ryan,

This is Raymond

I think this is another great use for TVO...a LanguageDisplay class could allow infinite language instances for each attribute...just an additional thought related to our core discussion.

Sounds cool to me

[xwisdom]

and in conjunction with the .dic files (or possible XML dictionary files? is there a related standard anywhere?), just access to these would be elementary

IMO,  flat delimited file would be much faster to parse and smaller to distribute.

modx|manager|1234|Hello Word

as oppose to:

<def rc="modx" rn="manager" si="1234">Hello Word</def>

What do you think?

[reportra]

I think it's necessary to point out that we've got 2 seperate things to support if we're talking about multilanguage support:

1. multilingual strings for the code (manager, snippets, plugins, etc.)
2. ability to create multilingual content

[xwisdom]

I think it's necessary to point out that we've got 2 seperate things to support if we're talking about multilanguage support:

1. multilingual strings for the code (manager, snippets, plugins, etc.)
2. ability to create multilingual content

The above dictionary files will solve the issue #1 - "multilingual strings for the code." Issue #2 is yet to be decided. Got any suggestions?

[reportra]

modx|manager|1234|Hello Word
<def rc="modx" rn="manager" si="1234">Hello Word</def>

Are you guys talking about distribution of language files or general storage of them?

For the distribution I'd suggest we seperate between classic snippets (to maintain compatibility to the eto 0.6) and to modx snippets which are defined in a xml container. On installation the necessary information is extracted from the xml and the language data is stored in the prefered way (db, flatfile..)

Code:

<xml>
  <head>
    <type>snippet</type>
    <name>newslisting</name>
    <author>a. lincoln</author>
    <version>0.1</version>
  </header>
  <language>
    <en>
      <id=1234>Welcome to Modx</id>
    </en>
    <de>
      <id=1234>Willkommen bei Modx</id>
    <de>
  </language>
  <code>
     for (i=0;i<10;i++) { echo $api->gettext(1234); }
  <code>
</xml>

This could be even used to create new database tables etc. or deinstallation parts (ie. delete language strings used by this snippet)

(I know this is not valid XML, it's just what came to my mind now I guess you get my idea)

[reportra]

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

[infoclipper]

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.  

[Luis]

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.

[Carsten]

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  

[reportra]

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)