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.
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.
Ok, but these features can be useful for other modules (like ecommerce). These additions can be contributed extensions to the tr or i18n module, like flexinode contributions.
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.
When I implement a site, I have to be sure that the technology won't be depreciated in the near future. I'd like to be sure. :) Bests, -- Aries