[development] Another translation module

[Rob Ellis]

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 at web.ca>
> >
> >  
> >
>