i18n of functional names and basis sets

I think translation of density functional names and basis set names should is absolutely useless. Large amount of this data in translation files only makes work of translator less convenient (it’s needed to skip large amount of strings, but there may be some other data among them). Also it distorts translation statistics

Regards,
Konstantin

Konstantin Tokarev a écrit :

I think translation of density functional names and basis set names should is absolutely useless. Large amount of this data in translation files only makes work of translator less convenient (it’s needed to skip large amount of strings, but there may be some other data among them). Also it distorts translation statistics

I completely agree with you.

Louis

I think translation of density functional names and basis set names should is absolutely useless. Large amount of this data in translation files only makes work of translator less convenient

I completely agree with you.

OK. Then we need to either:

  1. Change the extract-* scripts to filter out strings like B3LYP, etc.
  2. Go through all the UI files and mark these strings as non-translatable.

Either way, it would help to compile the list of non-translated strings.

-Geoff

01.04.10, 07:59, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

I think translation of density functional names and basis set names should is absolutely useless. Large amount of this data in translation files only makes work of translator less convenient

I completely agree with you.

OK. Then we need to either:

  1. Change the extract-* scripts to filter out strings like B3LYP, etc.
  2. Go through all the UI files and mark these strings as non-translatable.

I’ve run into problem - script merges new version, but doesn’t delete strings that are already present

Either way, it would help to compile the list of non-translated strings.

-Geoff


Regards,
Konstantin

Здесь спама нет http://mail.yandex.ru/nospam/sign

I’ve run into problem - script merges new version, but doesn’t delete strings that are already present

The strings should marked as deprecated in the PO file. It’s a technique in case there’s some mistake and you later add back the string for translation.

If you upload new templates to Launchpad, or open them in editors, the strings will disappear.

Cheers,
-Geoff

01.04.10, 13:10, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

I’ve run into problem - script merges new version, but doesn’t delete strings that are already present

The strings should marked as deprecated in the PO file.

But they aren’t. I’ve added script update-po.sh, it casts msgmerge -U on all po’s and unnecessary strings are marked deprecated.


Regards,
Konstantin