uc_get_field_name() breaks translation

Yeah, this is certainly some legacy code that will be fixed in 3.x, but your patch here isn't enough. It would basically preserve the translation for multilingual sites but leave an entire settings form inoperable since changes wouldn't be saved as users expect. My preferred solution would be to detect if the field name was left at its default setting. If so, return the translated string instead of the variable. Then you could still use the form for single language sites and multilingual sites could be instructed to use String Overrides.

How about if we tell the i18n module about those variables? There's a patch in a forum thread on ubercart.org that I think you'd be interested in. Multi-lingual customizable form element titles and messages

Here's the latest version of that patch, as well.

There's a bug in the 1.1 version of i18n that prevents the default English values from being displayed if a variable has been translated. It's been fixed, but a new release hasn't been made yet. I haven't committed this patch because I don't want to deal with all of the useless error reports that will cause.

However, we can't just leave this patch sit forever, so I added the "Release blocker" tag. It'll be in the next release even if i18n hasn't updated then.

Eh, I got tired of waiting. If people have problems seeing the English values that Ubercart provides by default, tell them to get the dev version of i18n. Or point them to #527534: Unset variables set to be multilingual don't show default values for the patch.

Committed.