Replacements for gettext

后端 未结 5 1696
野趣味
野趣味 2021-01-13 07:56

We use gettext for translations in our product, but have had a lot of problems with it:

  • Can\'t use a language unless the system supports it.

On

相关标签:
5条回答
  • 2021-01-13 08:31

    The language switching on the Google Chrome browser is very neatly done. It's possible to switch between languages while the program is running. I don't know what system they use, but it may be worth investigating, since it's an open source browser.

    0 讨论(0)
  • 2021-01-13 08:32

    1. Can't use a language unless the system supports it.

    Wrong. You may manually specify language. Using LANGUAGE environment variable

    int main()
    {
          setlocale(LC_ALL,"");
          setenv("LANGUAGE","foo");
    }
    

    This works, even if the locale does not exist (have you ever seen language foo?)

    2. Uses environment to work out language

    What is problem with that? This gives user more control.

    3. Can't set a default language

    Wrong, See above.

    4. Encoding the are returned vary between UTF-8 and current local encoding.

    Wrong, See bind_textdomain_codeset(domain,codepage);

    My strong recommendation -- stay withing gettext. It is one of most supported and best tool around. Translators will be thankful to use normal and useful tool.

    There is other important point: great support of plural forms that has quite bad support in non-gettext based tools.


    There is only 1 limitation of gettext -- you can't use more then one language per-process. It is not thread safe to switch language. Fortunately most programs that incract with human beings are speak in one language.

    This may be limitation only for multi-threading services.

    EDIT: But even this is not a real problem. I had implemented thread safe gettext version once for my project. See http://art-blog.no-ip.info/cppcms/blog/post/16, based on mo files reader.

    0 讨论(0)
  • 2021-01-13 08:37

    Can't use a language unless the system supports it.

    That has nothing to do with GNU gettext - because that only handles the translation part. But it's true, that if the system is not able to show any chinese characters, then you will have problems with China.

    Uses environment to work out language

    That's a good choice, but you can always set the language yourself, overriding the environment. This way, you can make it use any language, based on your choice.

    Can't set a default language

    That's incorrect - default language is always the built-in language, and if you want to have another language, just switch to it. It simply cannot be simpler than one line of code.

    Encoding the are returned vary between UTF-8 and current local encoding.

    If you're in the position to pick an internationalization tool, then you are also in the position to choose, what character encoding you want to use for your texts. Some projects use utf-8 for all languages (my preference), some use the locale encoding.

    Does anyone know of an open-source translation libraries that provide a more useful interface?

    No, sorry - I fail to see any problem with GNU gettext :-)

    0 讨论(0)
  • 2021-01-13 08:39

    You also can convert ICU resource bundles to and from the XML-based XLIFF format for translation.

    0 讨论(0)
  • 2021-01-13 08:46

    We are using ICU resource bundles and are pretty satisfied with it. The ICU interface is not "modern", but it is powerful, the underlying principles are sound, and resources packaging (with the genrb tool) is pretty flexible. Its message formatting capabilities are also good.

    About your specific comments:

    Can't use a language unless the system supports it.

    I don't understand this one. This may be due to the fact that the only "experience" I have with gettext is having read its documentation.

    Uses environment to work out language

    The ICU interface takes a Locale as input, so you have complete control. It also has a concept of "default locale" if it is more convenient to you.

    Can't set a default language

    ICU has an elaborate fallback mechanism, involving a "default" bundle

    Encoding the are returned vary between UTF-8 and current local encoding.

    String ResourceBundles (other data types are also possible) are always represented as UnicodeString, which is internally encoded in UTF-16. UTF-32 with UnicodeString is pretty easy, as its interface exposes several methods allowing to manipulate it at the codepoint level. For other encodings, code conversion is possible.

    0 讨论(0)
提交回复
热议问题