Question

简言之,我能否同时在python许多.mo上查阅同一种语文的档案?

在我的下午应用中,我需要为I18N使用gettext。这套系统使用一种pl。这意味着,你可以下载插头,将其放在适当的目录中,并像任何其他刺.包一样。主要应用程序储存<代码>。插图1本身有<条码>。

我将利用这一方式装载<代码>main.mo。 I18N 讯息:

gettext.install( main ,  ./locale , unicode=False)

我如何安放他人,以便所有pl子都能翻译他们应该怎样做?

我认为的解决办法是:

每一件“名称空间”中的“代码”应否? 但这将优先于先前定义的<代码>_(),并标明今后主要应用的译本。

是否有办法将两个<代码>.mo文档合并在一起(例如,安装了新的插图)?

At runtime can I combine them into one GNUTranslation object? Or override the default _() method that is added to the global namespace? Then, how would I go with that option? Instead of _( Hello World ), I would use _( plugin1 , Hello World in plug-in 1 )

注:该申请不应知道将要安装的所有插图,因此无法在其<代码>main.mo文档中翻译所有电文。

Answer 1

您应使用不同的omains。该领域可以是预防冲突的一揽子名称。

我不理解,为什么你需要利用原始领域,把一些东西放在原始的外面,但如果你真的需要,那么你就应当每次都不怀疑这个领域。

每一种金刚石都可以提供自己的“未得分”,很容易受原始金块的束缚:

from my.plugin import MessageFactory as _my_plugin

请注意,这只强调一项公约,这样,提取工具就能够在方案中找到可加18的信息。原始电文应当在各自的包件中加以强调(如果将它们单独列入一揽子计划,是正确的)。在所有其他地方,你可以自由地用其他名称来召集这些工厂,并在主要方案翻译领域留下强调。

我不太肯定,但你肯定能够把你的所有文件编成一个.mo的档案。然而,如果假想是由独立、不合作的作者写成的,就可能爆发冲突。

最新资料:

如果原始材料与主要数字相同,那么使用个人翻译领域就没有意义(这不是你的情况)。如果粉碎在单独的包件中,那么就应当对这些包裹进行独立提取。这两种情况都不存在变数问题。如果出于某种原因,主意想要在其法典中进行原始翻译,则像回答中那样使用其他名称。当然,开采工具不会发现任何东西,而是强调。

换言之,假想应自行处理翻译问题。主要的投影机可使用原样的翻译功能,作为普普朗戈-内普森的一部分。摘取或人工添加插图,使之成为纸面/活面文件,也并非主要内容所关切:它直至原始作者提供翻译。

Answer 2

gettext.install() installs the inalterable one and only _ into the builtins (module __builtin__ or builtins in py3) - app-global. This way there is no flexibility.
Note: Python name resolution order is: locals > module-globals > builtins .

因此,gettext.translation() (Class-based API) 或甚至gettext.GNUTranslations(例如,用于习俗.mo途径计划)将明确用于同时单独或混合式多种翻译。



一些备选办法:

通过<代码>t = 文本,翻译(......);_ = t.ugettext 您可以简单地将单独译文作为<代码>_输入每个模块-全球名称空间——或许在现实世界中更加自动化。也许主要译文也可上入(通过main_t.install()。
如果所有/多种翻译都是ok的,或者是你想要的,那么,你可以通过以下途径在全球链条:<条码>t.install();t.add_fallback(t_plugin1); t.add_fallback(t_plugin1);......;——并且以其他方式保持相对的全球做法。
gettext keywords other than _ could be used - and could be feed via the xgettext -k other_keyword option. But I d dislike lengthy and module-unique names.
( Yet personally I prefer the keyword I generally over _, and I also enable an operator scheme like I % "some text" instead of _("some text") or I("some text"). Via I = t; t.__call__ = t.__mod__ = t.ugettext effectively; plus a small patch of pygettext.py. This pattern is more pleasant for typing, looks more readable and Pythonic to me, and avoids the crucial/ugly name collision of _ in Python with the interactive-last-result-anaphor (see sys.displayhook) when using gettext ed modules on interactive Python prompts. _ is also "reserved" as my preferred (local) placeholder for unused values in expressions like _, _, x, y, z, _ = some_tuple.
After all gettext is a rather simple module & mechanism, and things are easily customizable in Python.)

友情链接