[development] Drupal and i18n, the holy grail?

[Benson Wong]

> The main changes accross the system would be.
> a) Having a language field for all the translatable objects that can be
> just ignored or:
> b) Joining simple language conditions when you want 'multilingual
> features enabled', that would be 'enabling i18n module'
>

Yep, so the support is there whether you use it or not.

I had a bunch of counter-arguments against your points, but I erased
them all because I can summarize with this.

1. The i18n module doesn't add multi-lingual node support. It adds a
language flags to a node. This is an important distiction because
you're still building two sites, they're just mashed together into one
through complexity.

2. Using a language in the URL, "namespace", is a great approach, but
it's just one intuitive way to designate the language. Totally
separate issue from #1.

3. If nodes are not truely multi-lingual, it is better to build a site
for each language. This will accomplish the same thing but in a
simplier fashion.

This starts falling apart if you're building anything bigger than a
brocure site.  See: http://www.ndp.ca, drupal, brochure site,
multi-lingual, yet very intuitive. Navigate to a node, and click the
'francais' link at top... that's how it should work.

4. FYI: I'm not hating on the i18n module, in fact, much props for
your work. Considering 4.7's i18n limitations, I just can't see any
benefits of using it over building a site for each language.

> If we provide some generic mechanism in core for handling I.e.
> multilingual nodes, the contributed modules don't need to worry at all
> about it. Same for whatever other object -menus, blocks, etc..

Agreed, +1 from me.

Ben.