What we mean by internationalization?

As I suspected before, there are two sides of i18n: data schema side and content creator side. In the data schema side you can mark a building block (eg. a form element, a content type field instance) which can be alternate. On the content creator side, when you fill the content, you can set the criteria and the result.
Eg:

• if $language is Hungarian, then the title should be ...
• if the $language set to English, the default currency should be USD
• if the $culture is european, $design_should_be = fancy :]

This approach can be general not for only i18n.

The main dilemma is how the alternate building blocks and their parent item? As a new attribute? As a new item (like translated node with new node id)?

Aries

Internationalization for me is enabling localization. The i18n part refers to the possibilities of the software. L10n is configuring the software to a specific locale.

So you can enable your software to support different languages or different regions (en vs en-us and en-uk). I think it should be clear what kind of 18n you want to introduce to drupal before development is started. I would like to suggest to limit it to only language.

Also, currently drupal assumes 'en' as the base language. This is a pain for people who want to use drupal without the english language enabled. Because if people make menu item's they have to be in english first (locales_source vs. local_target).

In my opinion there are only 3 types of 'translatables' (I don't want to use content, but I mean stuff that needs to be translated):

• labels
• content
• mixed

In the Drupal currently the interface is treated as labels and the nodes as content. Taxonomy is also handled as 'content' (I think, I'll have to check again) but it would be better if they were treated as labels.

How the underlying menu and content presentation works is all dependent on the choices made before. The i18n module currently does a lot right, only the navigation is a bit incomplete (but can be solved: http://drupal.org/node/76631)

For the ecommerce products having a separate node for each language isn't a good idea because when you translate a product you end up with a different node id for the new product and if you use the node id as reference you cannot reference the single fysical product anymore.

hmmm.. I'm going to stop rambling now. Anyway, I am really rooting for i18n in core in Drupal because I always need it. So I'll keep an eye on the groups and help/test/suggest where I can.

The question is how far should we go with internationalization?
As you said there's a lot more than just language, and I'm pretty sure everyone has a different approach to it...
As a european webdesigner I've worked (not as a developers, but in close collab with the developers) on lots of multilingual sites built on many systems for the past ten years, and most of them handled this problem poorly.
Some of these systems tried to address every need and were really bloated. Most used some kind of "duplicate document tree" strategy though, so it was just like maintaining two separate websites...

So, in Drupal apart from language what would we have to handle? Dates and time, currencies, addresses, files, etc... I think they fall into two categories: specific to a language, or specific to a geographical area. And to me language is a subset of the "areas". Let me explain...

What I imagined was a kind of i18n "profiles". What's this? A profile would be a collection of settings, to be used for an "area". I think it's important because even if two countries share the same language they may have different content or settings.

For example, you build a site for a Canadian company, which also has subsidiaries in France. You would have:

A profile for the area "Canada"
Languages: english (primary?) + french
Dates: mm/dd/yy
Currency: C$
...
A profile for the area "France"
Languages : french
dates: dd/mm/yy
Currency: €
...

When you enter the site you choose your area, and depending on your browser's settings a language may be selected.
Each area should have a default language, in case the browser has no preference than can be used.

Also a language could have a "fallback language", and this alone could enable you to easily share content between two areas with a common language.
Say, the fallback language for "France-Fr" is "Canada-Fr. 95% of the pages are identical, except a list of local subsidiaries and maybe the contact form. With this system when you write content for "Canada-Fr", it's also available for "France-Fr".
If you need a different page, Just create a "France-Fr" translation of the subsidiaries page, and voila, it will be shown only to users who chose "France" at the beginning.
All the other pages will fallback to the french-canadian pages.

I don't know if it's a good idea, I just wanted to share it ;)

in drupal-world theory, themes shouldn't be language dependent, but I think in most of my experiences, they are. Some of that is because I use the theme to make up for the shortcomings of Drupal's i18n support in the modules, but I suspect that it might always be true/necessary in some use-cases.

Conclusion - has anyone thought about how to tag a theme with a language? Example: I have two themes, one of which I want to use whenever a user is displaying a site with the english locale, and another for the french locale.

Or, alternatively, is there a nice way to take a theme and split off it's language dependent parts? I think this would be a better way, since a lot of the theme may be common. Ah, I'm remembering how civicspace has these 'subthemes', perhaps that's the best approach?

I think this connects to a previous posting that notices that some of the settings need to be multilingual, and already some of the settings are theme-dependent ...