Multilingual Support/Snippet Installation

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?

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.

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

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... ;-)

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

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

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?

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

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?

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..)



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)