Gettext后备不适用于未翻译的字符串

Gettext后备不适用于未翻译的字符串

问题描述:

在我的应用程序的源代码中,我用俄语包装了gettext字符串,因此这是我的默认语言和基于它的* .po文件. 现在,我需要创建后备链-在西班牙语目录中未翻译的字符串应在 english 目录中进行搜索,如果未翻译,则将其自身返回. 俄语.

In source code of my application I wrapped with gettext strings in russian, so this is my default language and *.po files based on it. Now I need to make fallbacks chain - string that doesn’t translated in spanish catalog should be searched in english catalog and than if it doesn’t translated will be returned itself in russian.

我尝试使用 add_fallback 方法执行此操作,但是 GNUTranslations(NullTranslations) self._catalog 中未翻译的字符串已经被其自身和 ugettext 方法从不进行回退.

I trying to do this with add_fallback method, but untranslated strings in self._catalog of GNUTranslations(NullTranslations) already replaced with itself and ugettext method never doing fallbacks.

我做错了什么?

示例:

当前语言环境为西班牙语,我们在西班牙语目录中没有针对字符串Титулдолженбытьуникальным"的翻译,因此应返回英语目录中的标题应唯一".

Current locale is Spanish, and we’ve got no translations for string "Титул должен быть уникальным" in Spanish catalog and as a result "Title should be unique" from English catalog should be returned.

西班牙语* .po文件

Spanish *.po file

msgid "Титул должен быть уникальным"
msgstr "" # <— We've got no translation for this string

英语* .po文件

msgid "Титул должен быть уникальным"
msgstr "Title should be unique"

俄语* .po文件不包含翻译,因为该语言用作源代码中的键(默认语言)

Russian *.po file does not contains translations, because this language used as keys in source code (default language)

msgid "Титул должен быть уникальным"
msgstr ""

我有了西班牙语翻译器(GNUTranslations的对象),并使用add_fallback方法为其添加了英语翻译器(GNUTranslations的对象)作为后备. 因此,我的es_translator._fallback是en_translator对象.

I’ve got Spanish translator (object of GNUTranslations), and I add English traslator (object of GNUTranslations) as fallback for it with add_fallback method. So, my es_translator._fallback is en_translator object.

ugettext 函数中,我们尝试通过消息作为键从 self._catalog 获取价值,并且只有在缺少它的情况下,我们才进行 self._fallback 强>通话. 但是用于未翻译字符串的self._catalog.get(message)返回字符串本身. self._catalog["Титул должен быть уникальным"] -> "Титул должен быть уникальным",我们永远不会在英文目录中进行搜索.

In ugettext function we trying to get value from self._catalog by message as key, and only if it is missing we doing self._fallback call. But self._catalog.get(message) for untranslated string return string itself. self._catalog["Титул должен быть уникальным"] -> "Титул должен быть уникальным" and we never doing search in English catalog.

def add_fallback(self, fallback):
    if self._fallback:
        self._fallback.add_fallback(fallback)
    else:
        self._fallback = fallback

def ugettext(self, message):
        missing = object()
        tmsg = self._catalog.get(message, missing)
        if tmsg is missing:
            if self._fallback:
                return self._fallback.ugettext(message)
            return unicode(message)
        return tmsg

但是,如果标记为模糊的消息不包含在self中._catalog和后备效果很好.

However if message marked as fuzzy it does’t include in self._catalog and fallback works well.

#, fuzzy
msgid "Отсутствуют файлы фотографий"
msgstr "Archivos de fotos ausentes"

好吧,python在执行添加功能方面与标准后备机制有所不同,该功能无法正常运行,就像您认为的那样.这可能会导致错误报告.

Ok, python is doing something different from the standard fallback mechanism for added functionality which is not working like you think it should. This may warrant a bug report.

如果字符串不在翻译中,则标准回退机制只有一个回退:使用源字符串.在大多数情况下,这是英语(C或POSIX语言环境不强制查找),但是在您的情况下,因为源C语言环境中的消息具有俄语文本(这可能会引起其他问题,因为有时C语言环境假定使用ascii而不是utf8).当前建议的最佳实践是在C语言环境中使用以7位ascii编码的英语,然后翻译为所有其他语言.这是一次重大的重新设计(并且承认是全球中心的),但是除非有人改进工具(这将是更加重大的重新设计),否则这可能是您最好的选择.

The standard fallback mechanism only has one fall back if a string is not in a translation: use the source string. In most cases this is english (the C or POSIX locale forces no lookups), but in your case because the messages in the source the C locale has russian text (which may cause other problems because sometimes the C locale assumes ascii not utf8). The current recommended best practice is to use english in the C locale encoded in seven bit ascii and then translate to all other languages. This is a significant redesign (and admittedly anglocentric) but unless someone improves the tools (which would be even more significant redesign) this is probably your best bet.