[development] Another translation module

[Rob Ellis]

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