Thread

I’m working on a bi-lingual site german/english as suggested by Cocoaholic. That means that I have 2 path-variables, $language (deutsch/english) and $language_code (de/en). If I use the std. setup all date formating as as well as the member panel etc seems to be selected according to the {lang} variable even if the selected language is different. This is somewhat confusing for the user and I want everything to be displayed as defined by the path-variables.

I think the most easy way achive this is to override {lang} just after it is finally defined. Is that possible and if so in which php-file? Or is there a better way?

I’m fuzzy on what’s going on re:

If I use the std. setup all date formating as as well as the member panel etc seems to be selected according to the {lang} variable even if the selected language is different.

Mostly because I’ve just wrestled with the same issue- and sounds like I had the exact opposite problem.  Running each language on a subdomain- I had trouble setting it so the localization was per subdomain/path.php file, rather than the configuration settings for the site.

Sounds like you experience the opposite- the language is based on the subdomain/path variables rather than the user’s/default language setting?  Am I reading that right?  And are you using one of the third party translation extensions/plugins/etc?

Sounds like you experience the opposite- the language is based on the subdomain/path variables rather than the user’s/default language setting?

Yes! Sorry that I was not clear. My English is rather poor.

And are you using one of the third party translation extensions/plugins/etc?

No. Are those plugins able to translate formatted dates etc? In general I worry about runtime efficiency using such tools.

That all is quite complicated because I use a independent template structure (which defines the language of the navigation as well as the sidebar and headers of articles) and the articles may even be in German as well as in English. I provide additionally the ability to map the translation into the other language-context.

To get the idea:
“/de/journal” maps finally on hidden templates like “.top-de”,”.content-de”,”.sidebar-de”. There is one weblog only for “journal” with a custom drop-down list which informs about the used language. Another weblog, “journal-translation” in this case, holds the translation (if available) and is be mapped via relationship into the selected language-context. Additionally the user can fetch the original text (via JavaScript) if he likes.

The reason for that structure is that the audience are often people with no or very limited english knowledge and third parties should be able to provide translations without having access to the the original text in the control panel.

Hm- there are about 3 language translation type plugins/modules out there now.  I haven’t used any yet- mostly because the only bit I found difficult was getting the language default to be set on a per subdomain basis.  I tried writing my own extension, never could get it to work, so I hacked it in.  Sounds like you’re in the same boat- everything works except for one little tweaky bit.  I can link you to the existing 3rd party offerings- you may find something helpful there.

But I’m still unclear on the last bit you have that doesn’t work.  Is it possible to link me to the example site- lay out exactly what it’s doing wrong- versus what it should be doing?  If I see it in action, I may understand it better.

I’ll send you access data via PM. Wait a minute.

If you need localizations for date formatting you could try using the setLocale variable as discussed in the thread. If you further need to override global language settings there is also an execelltent plug-in for that, Template language I think it’s called.

Thanks for the hint Yvonne,

but I’m looking for a more generic solution, not dates only. The selected language should be based on the subdomain/path variables rather than the user’s default language setting.

Robin,

did you get my PM. I’m not sure I did everything right.

Peter

I did- replied back.  I thought it looked right- at least, the Archive stuff- well, everything, looked to be in German.  Let me poke more- see if I can better understand what it should be doing vs. what it is doing.

OK- yea, you’re having the same problem I did.  What you want to do is override the user/default language setting via a value in the path.php file- so that if you’re on the english subdomain- then EE treats it as the English localization, on the German- the German localization, etc.

EE doesn’t do it this way by default- localization settings will be based on the logged in member’s preferences.  For a non-logged in viewer, it will be based on the site default.  To get it ignoring that, and using a path.php global instead?  You’d need to check out the third party extensions.  Or- what I ended up doing- hacking as per this thread.

I tried getting an extension working- as per this, but it didn’t and I stopped dinking with it.  But- I suspect one of the other multi-lingual 3rd party offerings would work.  I just needed to get past this blip and get the site up, so went with a hack.

Robin,

you mentions in the PM that there is no great solution but there should be one ! 😉

I think there must be somewhere in the PHP-Code one point where the user-settings are finally put into a PHP-Variable. If I can do on that point something like $LANG=$language_code everthing should be done, - provided there is this single point…

Another way might be to hack into the database and set the user-lang on the fly. But that would be probably too much runtime overhead.

Peter

Yea- we cross-posted.  There is- and it’s a simple hack.  SHOULD be able to do it with an extension, but I couldn’t get one working and didn’t want to muck with it anymore- so I hacked.

Anyhoo- x-post.  Think the answer is above.

OK, I’ll take a look into the PHP-code but if I do not find anything I’ll hack it as suggested.

Thanks!

Peter

PS: Multi-language is a mess…