On Mon, Nov 21, 2005 at 01:48:22PM +0100, Jose A. Reyero wrote:

Hi Rob,

I've been looking at your module, mostly looking for some new ideas to add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply

Jose, feel free to take anything. :-) The .htaccess patch applies for me on a fresh DRUPAL-4-6-3 checkout, and I just checked it with the tarball distribution and get: Hunk #1 succeeded at 58 with fuzz 1. I'll see if I can figure out what the 'fuzz 1' is about.

It seems to me that the data model to keep the translations is quite similar, and compatible in both modules, but the management of paths and links is quite different. Actually, I was thinking of adding some options about that 'links to node translations' in next version of i18n module.

I will have to install i18n again, I haven't done that for a while. There are two ways 'tr' can get the language: by parsing out a path prefix with mod_rewrite, or from matching the base url. I think the first is closer to what i18n is doing (?), but using mod_rewrite means that Drupal itself can handle the path normally after that. With 'sites' configurations, matching the base url might be cleaner, but it requires extra setup. The path parsing works with a default setup.

A few things I dont fully understand are: - What is the idea of that "System locale settings" ?

That's just to get the PHP locale setting right, which is useful, e.g., for using date functions in template code. That might not be the best place to do it. I was switching between FreeBSD and Linux environments, different versions, and finding that a pain.

- Why aren't you using locale strings for that "string_translation" table?

That string_translation code works, but it's there really as a stub for something better. I read on this list somewhere that the locale string translation wasn't a good thing to use for content translation. I forget why... something to do with scaling/cache/efficiency...? I'm mainly using it for menu titles, which have their own caching.

- Does it play nice with the cache system?

I think so. There may be things that need fixing there. The main thing it does is make per language cache ids, so the menu translations get cached differently.

Besides that, I think both modules share the same goal, and quite similar approach. So, could you tell me the features you are missing in i18n.module so maybe we can work out something together?

I will have to look at i18n again, I have to admit. When I started working on the problem, it was in February... There were more DB changes for i18n then, and I was worried about the extent of the core modifications (for keeping up with Drupal). The main thing that was missing was switching language based on the hostname, and the different path handling that entails. I also like the closer integration of translation editing with normal node editing in 'tr' -- no separate admin interface. This works well for just a few languages. I don't know how much demand there is for many-language sites where all the 'translate' tabs might be cluttered. Another thing you might want to look at is the hook into Drupal's url() function -- I found that ended up being simpler than getting into the path functions. - Rob

Rob Ellis wrote:

...

I just added yet another content translation module to CVS:

contributions/modules/tr

Apologies about the name, but 'translation' is already taken, and I couldn't think of something short-but-meaningful to use instead... 'tr' was used for development, so I just left it as that.

The module is a recent complete rewrite of something that was developed early this year for the Canadian New Democratic Party web site (www.ndp.ca). At the time, we had requirements that the existing i18n module didn't meet, and I wasn't aware of the contributed 'translation' module.

The 'tr' module in it's current incarnation is being used by my former employer for several sites, in french and english, english and inuktitut, and french and english and inuktitut... They're finding it useful.

Some features are:

- content switching based on language - language switching based on hostname or url-path-prefix or ?l=xx - per node 'translate' links for untranslated content - per language 'edit' links for existing translations - generated translation links for use in templates - custom 404 page for missing translations (optional -- will show untranslated content otherwise) - admin node list filtered by language or "untranslated" - translated taxonomy term names - translated menu item titles

It's a little sketchy in places, and it requires patches to the Drupal core, but small ones. The patches at the moment are for DRUPAL-4-6-3.

At least it might be interesting for people working on similar content translation schemes, and some people might find it useful as is.

I'm not sure about how to tag this initial import -- since the patches are for DRUPAL-4-6-3, I thought branching it for 4.6.3 would be the thing to do, but I'm not sure.

Help, comments would be appreciated.

Thanks.

- Rob

-- Rob Ellis <rob@web.ca>

Karoly Negyesi wrote:

...

the first is closer to what i18n is doing (?), but using mod_rewrite means that Drupal itself can handle the path normally after that.

aye and making the module useless on hosts without mod_rewrite.

I would not consider this a major problem. Drupal already uses its SEO friendliness without mod_rewrite. Cheers, Gerhard

On Mon, Nov 21, 2005 at 01:48:22PM +0100, Jose A. Reyero wrote:

I've been looking at your module, mostly looking for some new ideas to add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply

The problem was that the patch file had a cvs $Id$ in the context which was getting expanded by checking it out from cvs. I did 'cvs admin -ko patch.drupal', and I think that's fixed it. - Rob

On Tue, Nov 22, 2005 at 01:32:51PM +0100, Fehér János wrote:

Hi,

2005-11-21, h keltezéssel 13.48-kor Jose A. Reyero ezt írta:

...

I've been looking at your module, mostly looking for some new ideas to add into i18n module :-) -Btw, the .htaccess part of the patch doesn't apply

Do you have any specification or detailed roadmap about the future of i18n?

...

links is quite different. Actually, I was thinking of adding some options about that 'links to node translations' in next version of i18n module.

Absolutely agreed. Can we think about it as an other (kind) implementation of revisioning system?

...

Besides that, I think both modules share the same goal, and quite similar approach. So, could you tell me the features you are missing in i18n.module so maybe we can work out something together?

Relations between the original version and the translated one, not for only nodes but menu, taxonomy, etc.

That's one of the goals for the 'tr' module... fields for translating menu items are on the regular menu edit form, fields for translating taxonomy terms are on the taxonomy term form, node translation links are available when you view nodes, you can filter by language in the regular content admin interface.

My problem is that, when I switch to an other language, the node / taxonomy system won't switch. There's no real relation between the original and the translated site, they're separated.

'tr' uses generated links, content switching, and relations in the menu system to maintain those connections. Menu translation, where translated menu items link to translated content, is key.

But i18n are not just about translation, but date, currency, eg. formats, regions, countries, counties, taxes, currency rates and much much more. The developers should take care about that. Because it's a large problem, you should specify it before you try to implement them.

If you get the php system locale set correctly for the current language, php already has some functionality for handling locale differences that can be used in the template system (especially easy with phptemplates). E.g., you can use strftime() to generate local dates, etc. And if you know the requested language in the template, you can use if/else to make appropriate changes. I think off-loading a lot of the per-locale customization to templates and custom filters makes sense. I don't think you need to plan it all out in advance. - Rob -- Rob Ellis <rob@web.ca>

On Wed, Nov 23, 2005 at 12:19:38PM +0100, Fehér János wrote:

2005-11-22, k keltezéssel 08.51-kor Rob Ellis ezt írta:

...

That's one of the goals for the 'tr' module... fields for translating menu items are on the regular menu edit form, fields for translating taxonomy terms are on the taxonomy term form, node translation links are available when you view nodes, you can filter by language in the regular content admin interface.

I see. But why don't you extend the i18n.module? Jose said that the aproaches of the two module are the same.

The basic idea of associating nodes with a node_translation table and doing content switching is the same, but in several ways the two modules are quite different -- in how they determine the request language, in how they plug into Drupal's path functions, in how they handle content admin. My original decision not to use i18n was made back in February when i18n required core db modifications and generally was less developed than it is now. In the meantime, I worked on a few multi-lingual sites based on my own code, and got interested in the problem... When I had some time this fall I decided to write a new module from scratch based on what I'd learned. I'm hoping it will be useful to people, maybe as a contribution to i18n's development, I don't know. - Rob -- Rob Ellis <rob@web.ca>