So, I'm working on developing a site for a French client. This means I'll be running into many of the same roadblocks others have experienced when setting up international and multilingual Ubercart sites. As I do this, I'm trying to think forward to see how to implement translatable strings in such a way that they're good for everyone.
One of the major problems with the way Ubercart functions pertaining to multilingual usage is the fact that we have a lot of settings for customizable messages and customizable form element titles/values. For example, someone can rename the "Add to cart" button through a settings form. This is fine for a single language site, but once that value has been set on a multilingual site, you lose the ability to translate it more than one ways.
That led me to think of this over lunch...
What if for customizable messages and element we came up with some specific identifier for the field and always generated the text for it by "translating" that identifier through t(). For example, the add to cart button text would always be printed out using t('!add_to_cart_button_value'). We can then pass a replacement value that either uses the default t('Add to cart') or the customizable message if it's been configured in the settings form. This means that even if you configure the text (totally fine for a single language site), you could still translate it differently for other languages by translating '!add_to_cart_button_value' to whatever you wanted for that specific language, like 'Add to bag.'
I think the code would look something like this:
<?php
if (variable_get('add_to_cart_button_value', t('Add to cart')) == t('Add to cart')) {
$default = t('Add to cart');
}
else {
$default = variable_get('add_to_cart_button_value', '');
}
$form['add_to_cart'] = array(
'#type' => 'submit',
'#value' => t('!add_to_cart_button_value', array('!add_to_cart_button_value' => $default)),
);
?>Thoughts? Does this really solve anything? Am I overlooking something? Obviously, I'd come up with a helper API function that we could use instead of always having to determine the default like that, so this is purely concept that needs your refinement. 
