Hi there,
I'm just asking myself one things. Is there a way with ubercart to translate country name ?
As it's stored in the database I don't know how to do that ?
thanks
zmove
|
Ubercart |
|
|
|
||
|
Mon, 10/15/2007 - 03:57
Hi there, I'm just asking myself one things. Is there a way with ubercart to translate country name ? As it's stored in the database I don't know how to do that ? thanks zmove
Re: Translate country
Is my question stupid or nobody knows how to do ?
Re: Re: Translate country
normally you would go to locale module and search for that string and then replace it with something else ?!
Re: Re: Re: Translate country
I tried but no, countries are not made with t() function. They are stored in the database.
Re: Re: Re: Re: Translate country
so you want to do what, change them in the database once for all or tied to another translation?
Re: Re: Re: Re: Re: Translate country
In fact I have my website available in enflish and french. When a english guy want to buy products, I want to display an english list of countries. When a french guy want to buy products, I want to display a french list of countries. In the locale module, when I search for the english name to translate, I don't find it. I think it's because they are stored in a table and not setted up with a t('My country'); function. So I'm still looking for a way to translate these countries.
Re: Re: Re: Re: Re: Re: Translate country
There is no way at the moment... this is another case where translatable variables would be nice, but the pot extractor doesn't like them. I've still gotta chat w/ Gabor about it.
Status?
What is currently the status of this issue and what are the plans?
For the record
Ryan suggested a fix at: http://www.ubercart.org/forum/general_discussion/5753/countries_tables #1
Why not our own convention? Follow the example of Greece!
Drupal convention dictates that database strings are not supposed to be translated by their locale system. So why not introduce our own UC convention? The basic problem is here that a user from a country should be able to find his country name in his own language, isn't it? So why not oblige by convention that country / region contributors translate the country name in their own language? Greece for instance already did so. Why not consistently follow the Greek example?
Re: Why not our own convention? Follow the example of Greece!
But this is counter-intuitive if you have a localized interface. I disagree with the problem. It is not that a user from a country should be able to find their country - it's that a user set to a specific language should consistently see ALL CONTENT in that language. If you are set to English, all your countries should be in English, French in French, etc. Your proposal is a kind of fudge-fix that would at least mean people would be able find their own countries in most cases, but not all countries have one dominant language for a start, so it's not a real fix, IMHO. Also, if you're going to talk about Drupal convention then by convention Drupal's interface is always entirely English (US) and translations for other languages are supplied. So supplying country names in a language other than English would, in fact, break with convention. Technically the Greek file is wrong. I have created and tested a patch implementing Ryan's suggestion, which you can find here: It works and totally fixes the issue.
Re: Re: Why not our own convention? Follow the example of Greece
A language list in a language you don't understand is also counter intuitive. All solutions are compromises and I don't see a problem breaking conventions to help the underprivileged user that only speaks his own language. It was only a proposal, so don't go over the top, please. I've seen this solution elsewhere so it is not too far fetched. But it seems that you are in control here, so I let you have it if you need it.
Re: Re: Re: Why not our own convention? Follow the example of Gr
Hey, sorry... don't think I was attacking. Just saying I don't think CIF files in their own language are a good idea, implementing the Drupal t() function is not really a compromise - it works and provides the ability to users to provide a list of countries in any installed language, which is a total fix, rather than a country in own language semi-fix (which would, IMO, cause greater confusion and raise more problems). Anyway, don't take it badly. I shared my patch, just saying why I think CIF in own language is not a great idea. |
|