Looking for greener grass on the other side of the fence

I have some experience with and knowledge of LiveJournal and the way it does/they do i18n (and l12n), however, I'm currently way tired (having rehearsed twice today with two different groups, plus school, plus transport, plus being somewhat ill still, etc...) and so can't really think of how to describe the system. I might use the subject for an English assignment though, which will make it all fit together in a nice academic unit. I'll get back to you on this. :)

.. and the others Jose showed during his presentation at drupalcon.

When I first was looking for a cms I checked out a couple and xaraya and drupal in detail. Xaraya touted i18n in core which was very interesting to me but I really liked the way drupal was built, I found my way through the code instantly.

Then I also found out that the way i18n was built around that time (I think 4.3) allowed me to have translated labels, content but mixed comments which was one of the requirements of the site. They wanted that the content was translated but that everyone could view all comments. The i18n module in those days required patching core and creating tables for each content-type (eg nodes/comments) that you wanted in each language (eg. en_node, nl_node).

Anyway, I also read your post on the drupal devel list, and it's nice that it is being done the school way. First document what needs to be achieved, what you are going to achieve and how you are going to achieve it. Good luck!

I think OpenACS has incredible i18n capabilities. BTW, dotLRN is the main distro that added many features, but core is the same as OpenACS.

Internationalization has been achieved for the UI, not for content (yet).

Project page:

openacs.org/projects/openacs/packages/i18n

Old Project home (see its left bar!):

www.collaboraid.biz/extranet/i18n

Translation server (translations that go into CVS):

translate.openacs.org

Demo (personal site translations):

openacs.innova.uned.es
Note: The demo site will be renewed daily with a fresh checkout from CVS, AFAIK. It may happen that the server setup is corrupted. Then just wait a day or more. (Btw, it may also be in the process of the new checkout.)

Instructions to find i18n UI of the demo site :

• log in as admin into the dotLRN HEAD server (postgresql or oracle)
• click tab "control panel"
• click link ".LRN Site Wide Administration"
• click link "OpenACS Site-Wide Administration"
• click link "Internationalization/Localization"
• or simply go to http://openacs.innova.uned.es:8020/acs-lang/admin/ (username admin@test.test ; password admin)

• enable the locale you want (wait a few seconds)
• choose your UI language in the left footer of the page and return
• "Toggle translator mode" enables translating UI in place. You'll see green "O" appear that you can click to translate the UI. Notice that the i18n itself isn't localized but the rest is....
• now translate single keys, lookup messages, batch edit/translate modules (=package) et cetera.

I think it is very sophisticated. The problem lies in the amount of active and good translators, the enormous amount of message keys and the lack of collaboration between translators. For example, translation should avoid using words like "you" in most languages. In Dutch "you" could be translated with "u" or "jij", depending on audience. A collaboration tool for translators would be an important extension.

There is a lot of internationalization package in pear (http://pear.php.net/packages.php?catpid=28&catname=Internationalization) but this are not content management systems only solution for handling it. There is a solution for cakephp: http://wiki.cakephp.org/tutorials:i18n_v2 with pear:: translaton2 package, and an other without it: http://wiki.cakephp.org/tutorials:i18n, but I think this is not a good way.
And there is an ather solution in Ruby on rails: http://ri18n.berlios.de/ but this is very similar to our t() function.

Even though CityDesk isn't a web based CMS it is wortwhile looking at. The model they use makes it very easy to maintain a number of languages of a site.

I've developed a few sites in Swedish, English and Japanese using CityDesk and it is by far the easiest way to maintain multi-lingual sites that I have come across.

http://www.fogcreek.com/CityDesk/

Cheers,
Joakim

I'm trying it
http://johan.vanherreweghe.com
I'll be glad to help.

Hi there,

For a couple of years I'm developing a framework that can be used for php based sites (not only cms) and I'm currently using it with success. As everyone else I also needed to have multilingual support so I came down to a partialy custom i18n solution:

Texts are split to static and dynamic:

• Static texts are placed inside source code and are translated using .po files by gettext. You can find static texts in .php files and in .tpl (smarty) files. The .tpl handling was implemented using a customized version of smarty-gettext, by providing blocks like this one: {t}Hello World!{/t}
• Dynamic texts are those that come out of the database. For all parts/modules of the framework (and other modules based on it), there is a common infrastructure that handles the i18n process.

The idea of the dynamic translations is that the real text and the 'label' of it are different things (just like gettext does). For example, my name is 'Stefanos' but this is only the English representation of it, so the user database includes a pointer to the translations table that holds the translations of my name, even though I'm entering it using the interface. This means that the users table has an INTEGER column (which points to the translations) to hold the name instead of a VARCHAR.

To accomplish this a modifiable hierarchy is required to hold the data. This can be done using this table (postgresql):

CREATE SEQUENCE seq_i18n_str_hierarchy;
CREATE TABLE i18n_str_hierarchy (
        id              INTEGER
                        PRIMARY KEY
                        DEFAULT NEXTVAL('seq_i18n_str_hierarchy'),

        parentid        INTEGER
                        REFERENCES i18n_str_hierarchy(id)
                                ON DELETE CASCADE
                                ON UPDATE CASCADE,

        k               VARCHAR,

        v               VARCHAR,

        UNIQUE(parentid, k, v)
) WITHOUT OIDS;

This table can hold any hierarchy for every possible module.
sample data are:

 id  | parentid |       k       | v  
-----+----------+---------------+----
 152 |       92 | persons       | 4
 153 |      152 | firstname     | 

This is a hierarchy under node '92': 92->persons->firstname (for example: module1->submodule2->persons->firstname)
So, person with id 4 has the name that is defined by entries with id 153.
Notice that we need a key/value pair so that hierarchies can be relative to userids etc. If you think about it you'll find out that this may hold every sort of information in an well organized tree that can be viewed by a generic translation page and will not allow conflicts between modules

The translations are held in two separate tables:

--
-- Original strings to be translated
--
CREATE SEQUENCE seq_i18n_str;
CREATE TABLE i18n_str (
        id              INTEGER
                        PRIMARY KEY
                        REFERENCES i18n_str_hierarchy(id)
                                ON DELETE CASCADE
                                ON UPDATE CASCADE,

        str             TEXT,

        t_change        TIMESTAMP
                        DEFAULT CURRENT_TIMESTAMP
) WITHOUT OIDS;

--
-- Translated strings
--
CREATE TABLE i18n_str_tr (
        id              INTEGER
                        REFERENCES i18n_str(id)
                                ON DELETE CASCADE
                                ON UPDATE CASCADE,

        lang            VARCHAR,

        str_tr          TEXT,

        t_change        TIMESTAMP
                        DEFAULT CURRENT_TIMESTAMP

        PRIMARY KEY(id, lang)
) WITHOUT OIDS;

The original string is held in i18n_str:

 id  |                  str                   |          t_change          |
-----+----------------------------------------+----------------------------+
 153 | Stefanos                               | 2006-08-06 16:38:59.251161 |

and the translated strings in i18n_str_tr:

 id  | lang |                 str_tr                 |          t_change          
-----+------+----------------------------------------+----------------------------
 153 | en   | Stefanos                               | 2006-08-06 16:38:59.27115
 153 | el   | Στέφανος                               | 2006-08-06 16:38:59.279401

Having the lang as a string instead of a reference to another table was a choise I made because I believe that translated content are data that should not depend on the installation.

After that each module that needs to hold translations does something like this (in a table named test):

        firstname       INTEGER
                        NOT NULL
                        REFERENCES i18n_str(id)
                                ON DELETE RESTRICT
                                ON UPDATE CASCADE,

We need one more thing:

SELECT func_i18n_add_trigger('test', 'firstname');

This will add an on delete trigger to the 'test' table so that whenever an entry is removed the translations of it will also be removed.

By providing a set of i18n helper functions, the modules are able to retrieve the translations from the database with minimum coding. An array like this does the job:

i18nGetTranslatedStringById() is a best effort function that returns the translated string in the current (or a specified) language, or a default string (predefined language, string-id, whatever) if the translation doesn't exist. i18nGetTranslatedStringByIdOnly() searches only for a language and returns null if the translation is not found.

Of course the retrieval is a lot easier since the translated string id is held in the table and can be fetched without using the hierarchy any more:

There are some more things like metadata to identify the translated strings type (one-line text, pages etc) for easier editing but this is too much for a simple post.

I hope it helps...

Oh and one more thing... Personally I'm trying to provide as many translatable strings as possible. I currently enclose in {t}{/t} everything that is translatable and this includes the summary attribute of tables too. I believe that you should do it too since there are people out there that rely on summaries and other information like it and need the translations more than the rest of us...

<>