Hello, I want to translate store into my language. Can you tell me what files are responsible for language version. Thank you.
Wed, 08/08/2007 - 11:24
Re: Translation
ok, I found .po files and translate some of them in msgstr lines. But how to install this translation ?
Re: Re: Translation
I have just imported the content of the .po files via the locale module in drupal. it works.
Re: Re: Re: Translation
Awesome... sorry we weren't any help. I've actually never done any translation, but I'm glad you were able to work it out! If you have any tips for others or any program you're using, feel free to post it up here.
String List
Hey Ryan
I'm the guest in the above post, joined in the meantime.
Ãœbercart is cool! I plan on using it on a shop for specials here in switzerland starting in september...so time is running.
The translation I have downloaded from ubercart.de is good but not completely suited to switzerland as we are using slightly different terms. Is there a list of which strings are used where in Ubercart? with such a thing I could adapt some strings in the .po files to read them in again.
One more thing: when the user manipulates the cart, the status string goes 'your cart has been updated' in english. where can i change that?
thanks for the help and keep up the good work.
Chris
Re: String List
The "Your cart has been updated." string is a translatable string in uc_cart.module. You should be able to adjust this w/ the localizer, but I'm not expert on localization. The .po files we've shipped with Ubercart are bound to be outdated.
Re: Re: String List
i'm also using übercart on a bi-lingual site. most of the strings translated fine, except i'm having trouble with the text that can be set in admin/store/settings/checkout like "Next", "Review Order", "Submit Order", etc.
has anyone else had similar problems or know what the fix to this might be?
Re: Re: Re: String List
The particular strings you mention ("Review order", "Submit order") are actually not in the localization tables. They are stored and fetched in the variables table (at least a couple of releases ago). I did a quick "fix" by adding some t() functions in the cart module so that I could translate those strings.
Hope that helps.
______________
Thomas Kulvik
Ny Media AS
www.nymedia.no
Re: Re: Re: Re: String List
hey kulvik, thanks for your reply. i took a look in the cart.module and didn't manage to get those strings working. could you please be a bit more specific about what you did?
here is an example of one of the strings that isn't working as expected:
t('Next buttons on checkout panes say %text.', array('%text' => variable_get('uc_checkout_next_button', t('Next')))),here, %text should be 'Next' in english and 'Suivant' in french, but it always reads 'Next', even though the 'Next' string has been translated. it works if i change it to this:
t('Next buttons on checkout panes say ') . t('Next'),but that seems like a huge change to the code...
Re: Re: Re: Re: Re: String List
Maybe that line should be
<?php
t('Next buttons on checkout panes say %text.', array('%text' => t(variable_get('uc_checkout_next_button', 'Next'))));
?>The problem with this is that the translation string extractor might not have gotten t('Next') from somewhere else, and it is very likely that any particular value for 'uc_checkout_next_button' won't have a translation available. This value isn't likely to change, though, so you could add the translation to fr.po or whatever else you have manually. Repeat for every other time we need to translate a Drupal variable.
The bottom line is that translating user input is a lot of work for each individual site.
kulvik wrote:The particular
The particular strings you mention ("Review order", "Submit order") are actually not in the localization tables. They are stored and fetched in the variables table (at least a couple of releases ago). I did a quick "fix" by adding some t() functions in the cart module so that I could translate those strings.
Hope that helps.
______________
Thomas Kulvik
Ny Media AS
www.nymedia.no
Hi Guys,
This post from Thomas is quite old but I am experiencing the same issue with the latest, 1.5 version. Namely the "Review order" and "Submit order" buttons show in English even if they are translated. These are the only strings showing as English though on my site fortunately 
Any ideas? Is this a bug, or a feature?
PS: I followed Thomas's advice, and did find those two buttons texts in the Checkout settings where I chagned it to my language. Yet, this means that those buttons cannot be internationalized and have a multilingual shop.
HowTo get Variables translatable
Suggestion how to get variables translatable
This should be within the coding standards. Other input could work by the same logic, but will need a little more code. The idea is still very new 
I developed this to get messages like "incl. 19% VAT" configurable: Replace 'VAT' e.g. by 'GST' and translate it to all available languages on one edit screen. If you are from a country where you have to display VAT/GST before checkout, you should try version 0.3 of my VAT project at VAT/GST overview, configuration at /admin/store/settings/store/edit/display
Helper function:
<?php
/**
* Get the active or installed languages by locale. If locale is not installed the function returns $lang[0] = 'en'
* Used for setting forms to:
* - get variables translatable
* - offer configuration fields for all/active languages on one page
*
* Configuration 'all or active languages' through variable 'uc_admin_all_langs'
*/
function uc_languages(){
if (module_exists('locale')) {
$languages = locale_supported_languages(FALSE, variable_get('uc_admin_all_langs', FALSE));
foreach (array_keys($languages['name']) as $key) {
$langs[] = $key;
}
}
else {
// $locale is on any system, but if locale was never activated, the value is 'xx',
// after install / uninstall stays 'en'. Not sure how to solve it better.
$langs[] = $locale ? $locale : 'en';
}
return $langs;
}
?>How to create a configuration
<?php
function SOME_settings_form() {
// ...
// This configuration value has just sense if locale is active => conditional display
// required just once
if (module_exists('locale')) {
$form['uc_admin_all_langs'] = array(
'#type' => 'checkbox',
'#title' => t('Adminster all or active languages?'),
'#description' => t('Applies just if "locale" is installed. Check this to administer also not active languages.'),
'#default_value' => variable_get('uc_admin_all_langs', FALSE),
);
}
$langs = uc_languages();
// Show for each language a text field to enter the name you want to display
foreach ($langs as $lang) {
$description = t('How to call "VAT" in your country & languages if locale is installed. (!lg)', array('!lg' => $lang));
$form['uc_vat_name_'. $lang] = uc_textfield(t('VAT name') .' - '. $lang, variable_get('uc_vat_name_'. $lang, 'VAT'), TRUE, $description, 16, 16);
}
// ...
}
?>Use case
<?php
global $locale;
// $locale is always available, even if locale module is turned off. Defaults to 'en' or 'xx' => my uc_languages() requires here
if ($locale == 'xx') {
$locale = 'en';
}
if ($tax_rate && variable_get('uc_taxes_message', FALSE)) {
$suffix = '<span><a class="info" href="#"> * <span class="hidden small">'. t('incl.') .' '. $tax_rate . variable_get('uc_vat_name_'. $locale, 'VAT') .'</span></a></span>';
}
?>Looking forward what you think about, specially about the case $locale == 'xx',
Alex
@ Ryan:
"The .po files we've
@ Ryan:
"The .po files we've shipped with Ubercart are bound to be outdated" When can we expect uptodate ones? Now every user of Ubercart is translating on-the-fly by using Drupal's translation interface, without having easy options of sharing it with others.
Could you please provide complete, correct and future proof PO/POT files for sharability sake of the translations? This also makes the translation task more delegable between translators.
Re: @ Ryan:
"The .po files we've
Future-proof .po files will be hard to come by until we get a stable release, and we're still several releases away from that. Keeping them up to date has to be the responsibility of the Ãœbercart community because none of know anything besides English. (I may do an Esperanto translation at some point, if I get enough of a vocabulary and free time.) We're going to update the .pot files with each release to make the translation job easier, and any changes will hopefully be easy to find.
Re: Re: Translation
I also opt for the possibility of translating the workflow titles.
Shouldn't we post this as an feature request?
I did not check latest release, maybe it's taken care of already.
Kees
Re: Re: Re: Translation
Do either the i18n or localizer modules take care of this? I was told that's the solution for translating stored variables.
Re: Re: Re: Re: Translation
I don't know localizer.module. I know a little of i18N.module, it works mainly with the t() function for strings, and has it's own implementation for translating blocks, taxonomy and other stuff. The important part is linking translated stuff together (so blockX is known as translation from blockY f.e.).
I don't really understand what you mean by "stored variables". I think as long it's not t() parsed, it's never gonna be translated, but I'm not 100% sure.
I think this is a quit important issue though, thanks for giving it attention.
Regards,
Kees
Re: Translation
I'd like to point out that the "Add to cart" string has the problem mentionned for Next.
So I modified 8 lines in product.module and 1 line in product_kit.module
It's not everywhere, it's only in the submit buttons.
I haven't gotten that far as to see the same problem with other things. A lot of strings aren't translated (a good deal of them) in the french translation provided up to beta 1, used on a beta 2 install.
Hopefully the french translation team ( http://drupalfr.org ) can support ubercart as a core module for a special distribution as soon as ubercart 1.0 is out.
Re: Re: Translation
Thanks for digging this up, alliax. I think the ultimate solution will be to remove the user interface for customizing the text on these buttons and directing users who want to change these labels to use a module for the translation. As it is right now, Ubercart isn't very friendly for multi-lingual sites. 
i18n variables
Hello,
about the variable translation issue, I think it should work with the internationalization module. Only the i18n module would be needed, not the translation module.
You have to add an array in 'settings.php' containing the names of the variables you want to be translatable. Example :
$conf['i18n_variables'] = array(
'menu_primary_menu',
'contact_form_information',
'site_map_show_menus',
'site_map_message',
'site_name',
);Then, the associated textfields or textareas will be language aware : you enter the text in english, submit, switch language (using the i18n block), enter the translated text, submit and that's it.
I never tested it with ubercart (will soon ), but it should work the same.
Re: i18n variables
That would be excellent! Please let me know if you're able to test this so we can get it in some formal documentation here.
Re: Translation
Ok, just tested it :
- installed 'internationalization' module and enabled only 'internationalization' (formerly 'i18n')
- activated 'language switcher' block
- added this code in settings.php :
$conf['i18n_variables'] = array(
'uc_teaser_add_to_cart_text',
'uc_product_add_to_cart_text',
);Then, when I go to product settings, the language beeing set to english :
- the two 'add to cart' textfields are empty.
- the sentence This is a multilingual variable is added in each textfield's description
- enter 'Add to cart' twice, then submit
- switch language
- the textfields are empty
- enter the translated string twice, then submit
- go to a product node, and switch language : the 'Add to cart' button is translated accordingly
So, it works. But a drawback is that, as soon as you make a variable translatable, the default value is ignored (I had to enter 'Add to cart' again).
will investigate this later
Re: Re: Translation
Very exciting development. This is a shot in the dark, but can you do something like:
<?php
$conf['i18n_variables'] = array(
'uc_teaser_add_to_cart_text' => 'Add to cart',
'uc_product_add_to_cart_text' => 'Add to cart',
);
?>
Any easy way to figure variables out?
The i18n_variables way of hacking Ãœbercart into better language support is really neat, from a usability standpoint it is even acceptable for my customers to use.
Anyhow, it's a bit hard to figure out what variables go where. Sometimes the Theme developer module can give some hints, but often not. Now for example I couldn't figure out how to make flat rate labels multilingual. Any hints?
It'd be really cool if you could find a way to ease up this process. Providing a ready made code snippet (to put in settings.php) making all of the Ãœbercart core modules' variables multilingual would be great! Also some generic tool or instructions to help the process of figuring the variables out would be useful.
Merry Xmas!
labels
I didn't pay attention to the labels translation yet and i can't help you with it now, even if i will meet this issue too ...
Re: Any easy way to figure variables out?
@ronnqvist: Not every user input is saved as variables. After configuring everything go to phpmyadmin, view the table variables, order by name and show 500 records. Around 300 entries starting with "uc_" are the Ubercart variables. Alternatively you can find this list also at i18n Support (still totally experimental, does the same like the above patch for settings.php - maybe a little too complete atm).
Not variables are e.g. Attributes, Attribute Options & Shipping Labels... IMO we could solve this stuff through some module which copies the way i18n solves variables.
Re: Translation
Unfortunately, you can't do such things... this would be too easy
First, about this kind of code (without using i18n):
variable_get('uc_variable', t('Something'));
It will work as the variable is not initialized (ie not stored in the 'variable' table). Once the form (where the variable is used) is submitted, the provided default value will be ignored "forever", and so it will break translation.
IMHO, you can safely remove those t().
With i18n :
I examined the i18n code and realized that if a variable is initialized, its content will be shown in the multilingual textfield.
In the previous test, I had to type 'Add to cart' again, just because 'uc_product_add_to_cart_text' had not been stored yet.
So, first solution would be :
- Explicitly sets those variables during installation(in 'ubertcart.profile'). For instance:
variable_set('uc_product_add_to_cart_text','Add to cart'); - add the
$conf['i18_variables']in settings.php
This way, if the site in monolingual and not english, users will have to translate those textfields.
If the site is multilingual, users only have to install i18n, and translate textfields (which will be populated with the values set during install process).
Then, we could do a little better, by using the 'st' function :
variable_set('uc_product_add_to_cart_text', st('Add to cart'));
This would improve the monolingual case : variables initial values could be translated via .po files.
Will test the latter and report...
Re: Re: Translation
Very interesting. Thanks for your continued help and for the nice little write-up.
Re: Re: Re: Translation
I wonder... does anyone have experience or can they test out the following project in a multilingual setting?
http://drupal.org/project/translatable
It looks like it will do exactly what kulvik's been wishing we'd do all along.
what is the status of this issue
If i understand correctly, multi lingual stores are impossible with ubercart ,
for example because of the link "add to cart"
Hi,
Drupal/Ubercart based
Hi,
Drupal/Ubercart based projects can be entirely multilingual. It could happen that you encounter strings that aren't translatable. This would be a bug. please post an issue for that. I did not encounter untranslatable strings in the end-user part of the interface in recent Ubercart versions.
Good luck,
Kees
There are a couple of built-in strings
During the development of a multilingual Ubercart store I found a couple of non-multilingual strings.
These were Ubercart variables which provide customizations:
- Order statuses (Completed, Canceled, ... etc.)
- Address fields (First name, Last name, ... etc.)
- Product attributes
The first two category of strings are available in pot files but these aren't stored in the {variable} table and thus cannot be converted to a multilingual variable via i18n module. For example Order status real values reside in {uc_order_statuses} and it can only get value for one language.
Is there any other way to make these working without re-writing for ex. the uc_order.module corresponding functions?
Forgot to mention that I'm talking about Drupal 5.x here.
Checkout messages in multilingual setting
Hi,
we are developing a Drupal6 site with ubercart store in different languages (www.sweat-help.com) . I am trying to output the Checkout messages in cart/checkout/complete in the different languages we have but since these messages are in the DB I have to put them in a t() function in order to translate them, My problem is I do not find the file where these variables are called.
I thought it would be uc_cart.pages.inc but I am not sure which are the variables
Can anyone help?
Thanx
Multilingual ubershops
Please visit and contribute to:
http://www.ubercart.org/forum/internationalization/10878/i18n_issues_i_d...
How to translate the "Submit Order button" when Paypal ?
How to translate the "Submit Order" button when Paypal ?
Hello,
I managed to translate all the buttons but not the "Submit Order" button when customers pay through Paypal.
It is translated when they pay buy bank transfer but not with Paypal, and i can't understand why.
I translated some buttons with String overides module and when not possible I did it directly in the .module file.
Any help is welcome to translate this Paypal "Submit Order".
Thanks a lot.