Localization

[Steffo]

Hi,

I installed german language pack for OSCommerce. It works fine, if you use a browser with german language support, but if you have a english browser, OSCommerce switches to the english version, but I want German only.

German is already set to default. Any ideas what else I can do?

 

Thanks in advance!

Steffo

[MrPhil]

It's working as designed. application_top.php is supposed to ask the browser what language it's configured to use ('english' in your case), and select that for the language ($language variable). So, your browser will always override your default language setting. Personally, I don't think that's very good, but that's what it is for now. I would have used the default language setting, or at least, revert to it once the customer or administrator has logged in (use the browser's language as the store language [if supported] until the user [and their language preference] is established). From looking at the code, I think that's what it's supposed to do, but it's evidently broken.

 

There's also a chronic problem with $language ending up undefined or empty, causing osC to crash and burn. It should have some sort of fallback language (such as the defined store default language) if it can't read the browser's language.

[tgely]

@@Steffo

 

The problem is known, Configure your browser to the default german language. Most of the browsers has localized translated versions. Install german version.

 

If osc has not installed language sets (english) can cause crash. Delete english language (not used language collections) from directories if you dont use.

 

Finaly delete sessions, where find language defines.

[Steffo]

@@Gergely: Well, thx, but you underestimate the problem! Not all Germans use a german browser!!! And if they don't, the currency is also shown in US Dollar, which means the customer pays less!

If you are an osc developer, please take this problem seriously!

 

@@MrPhil: OK, this helps a little bit, thx.

Actually I can't program PHP, but I'll try to modify the code so that always the default language gets choosen. But I'll do this tomorrow. Since you seem to be good at php, maybe you could post some quick & dirty fix?

 

Best regards

Steffo

[Steffo]

Well this works for me:

 

language.php:

function set_language($language) {
 $this->language = $this->catalog_languages[DEFAULT_LANGUAGE];
}
function get_browser_language() {
 $this->language = $this->catalog_languages[DEFAULT_LANGUAGE];
}

[MrPhil]

I was going to suggest something similar for the browser part (replace the call to $lng->get_browser_language with $lng->set_language('de') or something similar) but ran out of time last night. I'll try to look at it tonight. I'm not sure about @@Steffo's change to the set_language method -- this will override whatever comes in on $_GET['language'] and I don't know if that's desirable behavior. If someone/something went to the trouble of adding &language='en' to the query string, I don't think we should override it.

 

Also, many users report problems with $language being undefined (attempt to include .../.php). I think a check needs to be added to force the default language if $language ends up empty. I just want to make sure it doesn't break anything with the session registration, and that the language_id is properly set, too. Anyway, problems with language selection are longstanding, and need to be carefully fixed.

[tgely]

@@Steffo

 

Is your fix all right? What about non german vendors? Should they read german text? We dont understand each other.

 

I found this problem with google chrome. I went to the chrome settings and config the default browser language. I think users problems not need bugfix seriously in oscommerce core. If a chrome user cant use chrome why should we do something?

 

You have problem with US dollars. How could you disable to pay in US dollars? Delete US dollars from currencies. The registered customers can pay in every installed currencies.

 

 

I hope this help.

:)

[tgely]

In the main english file

 

change

// if USE_DEFAULT_LANGUAGE_CURRENCY is true, use the following currency, instead of the applications default currency (used when changing language)
define('LANGUAGE_CURRENCY', 'USD');

 

to

// if USE_DEFAULT_LANGUAGE_CURRENCY is true, use the following currency, instead of the applications default currency (used when changing language)
define('LANGUAGE_CURRENCY', 'EUR');

[Steffo]

@@Gergely: So, if someone wants a german only shop, you want to deny this to your users?

 

If a chrome user cant use chrome why should we do something?

 

I'm sorry, but I wondered for hours(!) where this behaviour came from! How can I expect, that a customer, that has no clue about computers, to recognize(!) and solve this problem?!

 

There is an use case called: One language only - that's it! If I delete the english language support, I get a blank page with an english browser localization.

Of course there's an use case: Multilanguage support, but if I set German as default language, then I expect that the user has to switch the language manually (and of course my patch doesn't care about that, so, I thinkt it's your job to care about this).

 

Ignoring user requests, is the first step to become irrelevant in this market, sorry...

 

Greets

Steffo

[tgely]

@@Steffo

 

@@Steffo

 

If osc has not installed language sets (english) can cause crash. Delete english language (not used language collections) from directories if you dont use.

 

Finaly delete sessions, where find language defines.

[MrPhil]

Both the store and the admin have this code in their application_top.php files:

// set the language
if (!tep_session_is_registered('language') || isset($HTTP_GET_VARS['language'])) {
 if (!tep_session_is_registered('language')) {
    tep_session_register('language');
    tep_session_register('languages_id');
 }

 include(DIR_WS_CLASSES . 'language.php');
 $lng = new language();

 if (isset($HTTP_GET_VARS['language']) && tep_not_null($HTTP_GET_VARS['language'])) {
    $lng->set_language($HTTP_GET_VARS['language']);
 } else {
    $lng->get_browser_language();
 }

 $language = $lng->language['directory'];
 $languages_id = $lng->language['id'];
}

This is osC 2.3.3, since no one has specified a version. I think they're all pretty similar anyway.

 

Basically, if the 'language' session is not registered, or there is a Query String language=XX passed in, we go into this if-block. First, make sure 'language' and 'languages_id' sessions are registered. Create a language object $lng. Set the language to be used: preferably whatever query string language=XX was passed in to this page, with the browser configuration language as the fallback. Finally, set the variables $language and $languages_id from the database information on this language.

 

I see a couple of problems that need solving:

1. It seems to be possible to go through here without going through this if-block to set $language (as well as $languages_id), I've seen many reports of osC trying to load blahblah/.php, as $language wasn't set (or was empty). If the 'language' session is registered AND there is no query string for language=XX, I don't think we're going to go through this block. That has to be fixed in a manner that properly sets up $lng, $language, and $languages_id.
    
   
2. When the language is selected, the query string language=XX is the first choice, with the browser configuration language the fallback (second choice). Nowhere is the DEFAULT_LANGUAGE given a chance to be used. I would still use the query string as the first choice, but stick the DEFAULT_LANGUAGE in ahead of the browser language.
   

The second item is easier to deal with. Change

 if (isset($HTTP_GET_VARS['language']) && tep_not_null($HTTP_GET_VARS['language'])) {
    $lng->set_language($HTTP_GET_VARS['language']);
} else {
    $lng->get_browser_language();
}

to

 if (isset($HTTP_GET_VARS['language']) && tep_not_null($HTTP_GET_VARS['language'])) {
    // first choice is language=XX query string, if any
    $lng->set_language($HTTP_GET_VARS['language']);
} else {
    // second choice is DEFAULT_LANGUAGE selection, if any
    $lng->set_language('');
}

 

Now, it is possible that there is no valid default language, and we'll have to see if the browser had anything to say. So after

 $language = $lng->language['directory'];
$languages_id = $lng->language['id'];

check if $language is undefined or empty:

 if (!tep_not_null($language)) {
   // still don't have a language, so see if the browser suggests something
   // third choice is browser configuration language
   $lng->get_browser_language();
   $language = $lng->language['directory'];
   $languages_id = $lng->language['id'];

 

Did the browser fail to return a suitable language (maybe nothing, maybe Mongolian which you don't have installed)? So after all that, fall back to English (which should always be installed):

    if (!tep_not_null($language)) {
      $language = 'english';
      $languages_id = 1;
   }
}

I think English is ID 1, but maybe someone should check. Alternatively, you could do

    if (!tep_not_null($language)) {
      $lng->set_language('en');
      $language = $lng->language['directory'];
      $languages_id = $lng->language['id'];
   }

 

Finally, what if we managed so somehow avoid going through the if-block, and $language is therefore unset? After the closing } in this block, add

 if (!tep_not_null($language)) {
   // try the DEFAULT_LANGUAGE and then the browser, and then English
   $lng->set_language('');
   $language = $lng->language['directory'];
   $languages_id = $lng->language['id'];
   if (!tep_not_null($language)) {
      $lng->get_browser_language();
      $language = $lng->language['directory'];
      $languages_id = $lng->language['id'];
      if (!tep_not_null($language)) {
         // nothing yet? fall back to English
         $language = 'english';
         $languages_id = 1;
      }
   }
}

 

Hopefully that should do it. I just tossed this off the top of my head and have not had a chance to run it, so no promises. There are probably more elegant ways to do this, but I need to get to bed right now. Don't wait for me to test it -- it may be quite a while before I can do so. Back up your files before making these changes!

[MrPhil]

After a night's sleep, I find myself wishing that someone would explain these "sessions" that are being registered. Are they supposed to somehow automagically ensure that $language and $languages_id are properly set on each page? If so, does the order of operations (register session then set variables, or vice-versa) matter? Harald, are you listening?

 

If the session stuff is kind of independent, the above code could be simplified to check/register the sessions, and then check/reset the language if requested. Something like

is 'language' session registered?
  no --> register it

is $_GET[language] set?
  yes --> set new language, change $language and $languages_id

is $language now set?
  no --> try DEFAULT_LANGUAGE
  is $language now set?
     no --> try browser language setting
     is $language now set?
        no --> force English as the fallback (hard coded -- you are free to set some other fallback)

 

After all this, you should be guaranteed that $language and $languages_id are set to something valid. I'm guessing that a query string language=XX is for a request to change the language, but I'd like for someone to confirm that. If there is a 'language' session already registered, is that supposed to set $language and $languages_id for you? Has any of that behavior changed with PHP 5.x?

[Steffo]

@@Gergely: Well ok, obviously the sessions were the problem, when I deleted the english directory, but I have to do this manually in the database, right?

@@MrPhil: Thanks for your efforts, but because I don't know wheter your patch is beeing accepted or not, I prefer to maintain my little patch. It would be glad, if your solution works and would be accepted by the core developers...

 

Regards

Steffo

[tgely]

@@MrPhil

The session id generated by the server and saved into data table and cookies. So session id can get from everywhere and not easy to kill. For example Google Bots use sessions for long time, because save the first touch link when oscSid generated into the URL. In generally some bots come with '&language=xx' in links so bots should be intelligence to see a bad server requests. But i think you know these things.

 

Some weeks before just fight hard against sessions for this reason. One my client use english Crome and used multi language shop. The uninstall was not enough. If I remember good he used language=en link parameters and always crashed.

Finaly I deleted all english sets and killed everything.

 

@@Steffo

After uninstall english languge in admin panel delete all english sets from the shop. (if you use configuration cache conribution you have to reset configuration cache too)

 

yes you have to delete manually the records, and start a new session by easy way.

 

In phpMyadmin panel you can run this code:

truncate sessions;

 

I suggest to delete cookies before exit browser and run again.

 

I hope this help.

[MrPhil]

@@MrPhil: Thanks for your efforts, but because I don't know wheter your patch is beeing accepted or not, I prefer to maintain my little patch. It would be glad, if your solution works and would be accepted by the core developers...

 

Unless Harald and Company are moving much, much faster than I'm aware of, no one has even started to look at this patch. It hasn't been officially submitted anywhere. I just threw something together (untested) to try to address the two constant problems in this area -- ignoring the default language setting in favor of the browser's language setting, and having $language frequently end up unset. I think a major rewrite of this section is needed, and hopefully I've given some ideas to whoever is looking at this.

 

BTW, why are people so insistent on removing English? Doesn't osC fall back to English in certain situations?

[Steffo]

BTW, why are people so insistent on removing English? Doesn't osC fall back to English in certain situations?

Do you mean me? I just want to have German as default and maintaining two languages is more tedious, because you have to write two product descriptions...

 

Regards

Steffo

[tgely]

@@MrPhil

 

Hi Phil,

 

i know your problem. If you take a commit in the github or make bug reports probably Harald will see. I will keep my eyes on this bug and your solution.

[burt]

I'm not sure there is a problem...

 

If you want only German as the language of your shop, then uninstall English.

 

Anyone with a english browser then sees the German version, no?

[tgely]

@@burt

 

if you have more language and german wanted to default store language, this solution would be usefull.