Suggest a small change in code for easier multi language sites

15 replies [Last post]

Tue, 09/04/2007 - 04:42

quaoar

Offline

Joined: 08/08/2007

Juice: 179

I find this code a bit difficult to work with:

  $form['continue'] = array('#type' => 'submit', '#value' => variable_get('uc_checkout_review_button', t('Review Order')));

Why is it not written like this:

$form['continue'] = array('#type' => 'submit', '#value' => t('Review Order'));

The value in the database will only support one language. So if the value for variable_get('uc_checkout_review_button') is "Review Order" in the database, it will always be "Review Order" overriding the actual language chosen by the user. Or for us in Norway, if the value is "GjennomgÃƒÂ¥ ordre", then it will be "GjennomgÃƒÂ¥ ordre" for international customers too.
Several places and especially for the checkout process variable_get('') is used for names for fields and buttons which increases the difficulty of supporting more than one language.

Erlend StrÃ¸msvik
Ny Media AS
erlend@nymedia.no

Tue, 09/04/2007 - 10:42

#1 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Suggest a small change in code for easier multi language sit

Hmm.. the rationale originally was folks were requesting the option to change the text of that button from "Review Order" to something else. There are cases like this all over the code where text values are pulled from variables instead of translations. I wonder what the best way to handle these instances would be?

I can only think of the (time consuming?) solution of adding an if-check to see if a non-default value has been specified and only then using the variable. Otherwise have it use the t('Review Order') by default.

Mon, 09/17/2007 - 06:53

#2 View page

smb488292

Offline

Joined: 09/16/2007

Juice: 19

Language Issues

Ryan said:
Hmm.. the rationale originally was folks were requesting the option to change the text of that button from "Review Order" to something else.

Which means that every Drupal installer doing a language translation has to duplicate the work of every other language translator.

There are cases like this all over the code where text values are pulled from variables instead of translations. I wonder what the best way to handle these instances would be?

You really aught to take a look at how strings are handled in http://drupal.org/handbook/modules/locale . This is one of the fundamentals of making Drupal international.

One caution, though. Don't be tempted to hard-wire "language" to "locale". The Locale Module writers missed the subtle difference in meaning. To be sure "locale" variables are supposed to be associated with country and region-related issues (like date format, currency, weights & measures, etc.) but languages cross locale boundaries. Some countries have two or three official languages. Not that the module writers got their coding wrong. They just named their module wrong. It should have been called what it is: the language module.

Anyway, it is dangerous to make too many assumptions about the individual user/buyer/etc. based on their location. Case in point, it is virtually impossible for me to get to the English support pages at Microsoft.com. Their CMS uses my IP address to determine my location then redirecting me to their Japanese site. The only way I can over-ride it is to go through a proxy server located in an English country. Google does it too but at least provides a link back to the English page and then remembers my choice.

A Japanese person in Canada will likely want to select "Canada" as his local so he can use Canadian dollars, but still choose his native Japanese language for the interface, but he should still have the choice of French or English, too.

I am a native English speaker who is located in Japan. I am the typical road warrior: My interface of choice is English but I still have my computer settings to Japanese locale while in Japan. So my default currency, date format, etc. same as for Japan.

As a general rule, all locale settings should have a default value (taken for the chosen locale parameter block) but each setting should be able to be edited/over-ridden by the user. Further, the language and currency settings should be in a locale block right on every page (like OScommerce).

It doesn't solve every problem, though. Another "locale" issue I have is trying to order online using a Canadian Credit card. Aside from the usual problem of my IP address not matching the country of origin of my credit card number (also solved by the proxy server). (Given a choice, I will still pay in Canadian dollars because it avoids the extortive Visa exchange rates.) Similar problem is Apple computer (Canada) won't ship to Japan. They tell me to go to the Japanese website. The Japanese website has no English and won't accept my Canadian Credit card. I point that out to them and they just told me "Get a Japanese credit card". Yeah, right. And while I'm in Hong Kong I'll just get a HK credit card and when in Bangkok....

Stephen
Hardfocus Media
Japan

Tue, 09/04/2007 - 10:46

#3 View page

Lyle

Offline

Joined: 08/07/2007

Juice: 6846

Re: Suggest a small change in code for easier multi language sit

How well would it work if we had something like this?

<?php
$form['continue'] = array('#type' => 'submit', '#value' => t(variable_get('uc_checkout_review_button', t('Review Order'))));
?>

This would save the English phrase in the database, and translate it when it is retrieved. It also allows customization because you can enter a new English phrase and put an entry for it in your po files. For those who don't want to muck about with po files, the default should still be available.

Tue, 09/04/2007 - 12:27

#4 View page

kulvik

Offline

Joined: 08/14/2007

Juice: 336

Thumbs up for Lyle Anything

Thumbs up for Lyle Anything but the current solution. I hate to hack the ÃƒÂ¼bermodules

______________
Thomas Kulvik
Ny Media AS
www.nymedia.no

Tue, 09/04/2007 - 12:41

#5 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Thumbs up for Lyle Anything

Alrighty, I'll start to change those in the (near?) future.

Unrelated question for anyone from Ny Media... are any of you heading down to Barcelona for Drupalcon?

Tue, 09/04/2007 - 15:23

#6 View page

kulvik

Offline

Joined: 08/14/2007

Juice: 336

Unfortunately no one in Ny Media could find the time to travel to Drupalcon this year. We were hoping to get a chance to meet the ÃƒÂ¼berpeople, but we'll just have to put it on our schedule for next year. I guess we'll just have to join the other drupalcon wannabees following the event from home.

______________
Thomas Kulvik
Ny Media AS
www.nymedia.no

Wed, 09/05/2007 - 05:04

#7 View page

quaoar

Offline

Joined: 08/08/2007

Juice: 179

Re: Hi

That would probably work, Lyle!

We could also save the first call to t() there by just writing t(variable_get('uc_checkout_review_button', 'Review Order'))
*must save those precious CPU-cycles*

Erlend StrÃ¸msvik
Ny Media AS
erlend@nymedia.no

Wed, 09/05/2007 - 05:21

#8 View page

kulvik

Offline

Joined: 08/14/2007

Juice: 336

*must save those precious

*must save those precious CPU-cycles*

Oh my... the Ny Media geek nerd strikes again
*running to lunch before someone starts pulling out their guns*

______________
Thomas Kulvik
Ny Media AS
www.nymedia.no

Wed, 09/05/2007 - 08:42

#9 View page

Lyle

Offline

Joined: 08/07/2007

Juice: 6846

Re: Re: Hi

That's what I had at first, Erlend, but Ryan mentioned that we'd still have to have translation strings for "Review Order" too. With the second t(), the extractor script will find it.

Mon, 09/24/2007 - 14:44

#10 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Re: Hi

Regarding the idea of syntax something like this:

<?php
  t(variable_get('uc_checkout_review_button', 'Review Order'));
?>

I talked with Gabor, the man behind multi-language/translation stuff for Drupal 6, at Drupalcon and was told this is an improper use of the t() function. It should only be used for literals hard coded into the source. We'll have to find some alternate solution for the case of buttons that can be renamed. It may be that we simply need to do away with the option and let folks on single language sites that want different wording use the locale module themselves.

Thoughts?

Mon, 09/24/2007 - 16:43

#11 View page

mikejoconnor

Offline

Joined: 08/07/2007

Juice: 536

Re: Re: Re: Hi

I'd ask around and see how other people are accomplishing this, or see what Gabor would suggest. If he knows that it is improper, it would seem logical that he would know the proper way.

Mike O.

Commerce Guys | Ubercart Development | Ubercart Training

Mon, 09/24/2007 - 16:54

#12 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Re: Re: Re: Hi

In our chat, his suggestion was simply using hook_form_alter(). Sites that need multiple values for the button could use the hook to add a submit handler to the form. They could define that handler function to mimic the checkout form submit handler for the default button.

Mon, 09/24/2007 - 16:56

#13 View page

kulvik

Offline

Joined: 08/14/2007

Juice: 336

Re: Re: Re: Hi

Did he mention why he said this is a inproper use of the function? Because right now this actually works fine for us

______________
Best regards,
Thomas Kulvik
Ny Media AS
www.nymedia.no

Mon, 09/24/2007 - 17:03

#14 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Re: Re: Re: Hi

Well, he said that it should indeed work fine, it's just not an intended use of the function. So it's not improper in that it won't work, but improper in that the need should be addressed in another way. Not a big deal for a site to customize this way, but not something we should put in core.

We need our use of t() to be consistent w/ Drupal's for other reasons... like the extractor module and possibly other translation aiding modules will put up errors if we're doing something dirty.

Mon, 09/24/2007 - 17:32

#15 View page

kulvik

Offline

Joined: 08/14/2007

Juice: 336

I see. Well, it would be

I see.

Well, it would be nice if you could keep us updated on this one if you get a chance to communicate with him

______________
Best regards,
Thomas Kulvik
Ny Media AS
www.nymedia.no

	User login
	Log in using OpenID: What is OpenID? Username or e-mail: * Password: * Remember me Log in using OpenID Cancel OpenID login Create new account Request new password

Ubercart

Navigation

User login