When is it supposed to have i18n working with Drupal CVS

this patch fixes that. It uses $languages = array_pop(locale_supported_languages());

Also it runs a dbquery once, because i18n needs to know the array of languages before the locale_supported_languages() function is defined.

Ber

This reminds me that I always should check the patches before uploading them :(

The current patch is the correct one (and not a patch of my tweaked drupal against HEAD ;) )

Applied the patch to:
// $Id: i18n.module,v 1.6 2004/07/31 20:02:50 ber Exp $
// $Id: i18n.inc,v 1.4 2004/07/31 20:02:50 ber Exp $

but, while content translation works (it is correctly changing db_prefix), interface language remains the one set by user profile.
Tried doing some debug, but do not understand where it is failing.

It is failing because in previous versions of Drupal, i18n reordered the $languages array, thus setting the default language for each request. Yes, I know it was an ugly hack, but I wanted it to work without patching the core...

It is not possible anymore, because of the new locale initialization system, so I think that some patching to the core - to the 'locale_initialize' function- will be unavoidable for i18n to work properly with current cvs version.

Jose,
since I understand the new Drupal 4.5 will not address directly site internationalization, are you going to provide such a hack ?? If so, when ??
For my purposes, i18n is A NEED, so if you need any help, I can test the module for you, or even help you in coding (even if I don't know very well Drupal Core).
Please let me know,
Matteo (m dot ferrari at tiscali dot net)

While I did not test the patches really extensive, I never saw this but. My excuse for that.
But, It works for me /only/ when i have:
a) session based langiuage settings enabled. The cookies and the url rewriting did not work
b) no language set in the profile.

I think b) can be solved by forcing a change in the $user->language ,and changing it in the profile, might help. But that might not be a very nice solution.
About a): I don' t know about you, but I dont really like the /en/node/something solution, It far too error-sensitive. There are loads of places where modules grep on $POST['q'] directly, or by arg(2) etc. with sessions you dont have that problem. Cookies might be another solution. But personally i am not afan of using them. They (cookies) seem to have a bad name under i-net users.

I think the best should be to integrate i18n into Drupal 4.5 (combining locale and i18n).
The needs for a locale a nd for internationalization are oftren correlated.
In the meantime, is anyone working on a temporary fix.
I can help, if needed.
Matteo

Bummer :\

I was looking at a decent CMS that we can use for a central Jabber Community site and according to

http://www.cmsmatrix.org/matrix

Drupal has built in 'Web-based Translation Management', apparently not. No biggy because someone seems to have created an i18n module, it's just a pity that Drupal doesn't support something 'core' as this out of the box and without weird array reordering hacks :D

Hmm, I'm not adding anything useful here, am I? :D I'll be on my way trying out the 'old' Drupal version with the i18n module.

BTW using only a session or cookie to change the language is not a very clean solution because this sucks for search engines and it also gives strange results for endusers when they are copy/pasting links. User A will see a Dutch version and User B (that received a link from User A) will see the English version. Pretty confusing. Can't really offer a solution to this because I don't have a clue as to how Drupal currently works internally :D

Let's go question by question...

Jose, since I understand the new Drupal 4.5 will not address directly site internationalization, are you going to provide such a hack ??
Yes
If so, when ??
This is a more difficult one ;-). As I am not currently engaged in any Drupal related project, it's not a priority for me right now. I will probably wait for the new Drupal 4.5 to be released, just to save time and not having to generate and regenerate patches again.

If anybody is really in a hurry to get the module working with 4.5, well... freelance.reyero.net.

Anyway, if anybody else wants to do the work right now (Ber?), it would be great and I could give him some support by e-mail... But I insist: this new one looks like it *requires* some patches to core.

I think the best should be to integrate i18n into Drupal 4.5
Sure, no doubt abt that, go for it in the development list...
I did give it a try and read things like 'it's not a priority right now', 'let's see' and 'anyway, most of drupal sites use only one language...' -- sure, as Drupal DOES NOT support multi-language sites :-)

I dont really like the /en/node/something solution
About this, I completely agree with bartvb and think it is the best solution. I was even thinking about dropping the cookies and the session methods in the future... anyway I will keep them if, at it seems to be, somebody finds them better...

Regards,

P.S: I was working in a new version which supported also 'language dependent variables'. But as the module is not working anymore with Drupal head I think it all should be reworked... :_(

Hi,

> Let's go question by question...

Some answers.

> Anyway, if anybody else wants to do the work right now (Ber?), it would
> be great and I could give him some support by e-mail... But I insist:
> this new one looks like it *requires* some patches to core.
I was in a hurry, but onfortunately, the project that needed this is on hold untill at least october.
So I will not be working on this, untill this project re-starts, or untill another project comes up that needs a multilingual interface.

> I think the best should be to integrate i18n into Drupal 4.5
> Sure, no doubt abt that, go for it in the development list...
> I did give it a try and read things like 'it's not a priority right
> now', 'let's see' and 'anyway, most of drupal sites use only one
> language...' -- sure, as Drupal DOES NOT support multi-language sites

Yes. But on the other sid, there is a group of people that do need multilingual content.
Most sites indeed need only locale, to translate the interface into one language.

Please, please, with sugar on top, will all people who need a multilingual functionality get together, post a message here, so that we have a listof people who are willing to help getting this into core?

> I dont really like the /en/node/something solution
> About this, I completely agree with bartvb and think it is the best
> solution. I was even thinking about dropping the cookies and the
> session methods in the future... anyway I will keep them if, at it
> seems to be, somebody finds them better...

I think we should indeed just use one system, that works. the reason why i do not really like en/node/something solution is because it becomes quite complex to handle aliasses. A handmade alias for a node will give problems, even if we protect users from making mistakes, the default drupal alias ssytem does not allow for easy /en/alias systems.

--
Regards,
[Ber Kessels | http://www.webschuur.com]

Hi,

I'm one of the people that really needs internationalization support in drupal. I considered Xaraya and Drupal as CMS and Drupal looks great. Xaraya is way more complex and I do not need that complexity at the moment. I got Drupal configured exactly how I wanted in a couple of hours, only lacking the i18n.

So, +1 vote for having internationalization in the core.

Please look at my posts regarding a possible bug + fix in the i18n module.

Regards,
Olivier

I can do some work, if you help me.
Even if my project is not commercial, I need to add internationalization support at least to Taxonomy. I hacked taxonomy module to translate terms and vocabularies, but this solution is bad and I don't like it.

Tell me how we can proceed..
Matteo

I don't know what version you are using - for me taxonomy, nodes and flexinodes are working well - download it from
http://drupal.org/project/issues/i18n

If you want to help, consider this thread
http://drupal.org/node/view/10711

romca

To get URL rewrite working, I've attached a patch. I'll look into locale.module and provide a patch.

Actually, it's a common.inc patch. But it's only two lines.

OK, it's not up to Drupal coding standards. Here's a fix.

And the common.inc patch

chx,

I tried your patches today, they work very well! But they do not apply cleanly unfortunately, due to some extra whitespace you had added.

patching with ignore whitespace should do the trck though.

Ber

Good news! common.inc is patched. As soon as the i18n.module get patched, this topic can be closed.

Someone please review this patch. I would not like to commit it without someone checking it.

And of course, there is one more question: who can commit a patch against i18n? It seems that the last changes are made by ber. I do not know the rules of patching a module made by someone else. Is this documented somewhere? Or is it based on common courtesy?

I contacted the author about committing and patching.

Furthermore: The i18n with patches et al work and are live @ http://www.thermal-elements.com/ where I translated menu's, flexinodes, interface and taxonomy. just one language, but all seems to work well. Only syncronising of menu's and sequences still have bugs. I plan to propvide a patch after finishing this project.

Ber

About the patches...

I think they may work, but also think there might be some issues: The module relies on the $languages array set in the config file and, since it looks like it has been removed some functions should be partially rewritten.... -well, it can work if you keep it in the config file...

In my oppinion the common.inc patch is in the right direction, but it needs some additional checking about the "translate interface" and "translate content" options of the module. Has anyone tested what happens when you have the module enabled but these options unchecked? Do the new 'locale' module settings -like the deffault language work? I suspect it will break something...

My proposal...

Well, we have the patches available on line, so anybody is free to apply them in their local copy. So let's give them some more testing and polishing before start patching and re-patching...

About when...

Ok, as it seems there are many people interested, I will try to have it all fixed for the end of this week. Otherwise, I will be applying the current patches as late as next monday.

Is it ok for everybody?

I desperately need this module to work as soon as possible with 4.4.2. I had had some problems with URL rewriting, and posted a forum entry about it, but received no response. I was intending to give myself a crash course in i18n programming and go it alone, so I'm glad someone else is looking at this, too. One thing I'd like to clarify is whether chx's URL rewriting patches above fix general problems with the module, or just inconsistencies with the CVS version. Could anyone clarify this?

The URL rewrite patch fixed a great many problems in my site (added language to menus, unified language within content). It fixed almost everything. The single remaining problem that I have is that my language box doesn't work. If I'm in English, the link to switch to French ends in "/fr/fr". The language entry is added twice to the url. If I switch between languages, my url to switch actually grows, and ends up as "siteurl/fr/en/fr". I traced through and found that, while $i18n_langpath is temporarily cleared in i18n_l (hopefully to avoid url aliasing), it gets reset by chx's patch in i18n_url_rewrite, which is eventually called as a result of l() calling url() calling drupal_get_normal_path() which calls conf_url_rewrite() with a value of "incoming" (causing the dreaded url aliasing). I'd be tempted to fix it myself, but my understanding is veeeeerry tenuous. Can someone intelligent please have a look at it?

For 4.4 you should *not* use CVS! this thread is about fixing i18n for the upcomuing release. Please open up a new thread if you have problems with the 4.4 version of i18n on a 4.4 drupal installation!
On http://drupal.org/project/i18n you can download the 4.4 version.

Ber

Hi All

Just commited a new version in HEAD, with bug fixes - all, I hope ;-) and some new features.

Some changes in the configuration, so please read the new docs and reconfigure the module.

I'm closing this issue -which is getting too long-. Please open new ones if bugs remaing or there are new ones.