I18N/L10N support for plugins
|Reported by:||Pedro Algarvio, aka, s0undt3ch||Owned by:||Christian Boos|
I'm opening this ticket to get some opinions on how the localization of trac plugins should be done.
There are several options:
- Merge trac catalogs and plugin catalogs at runtime, but this might be a disadvantage because while merging catalogs, if 2 of them share the same msgid, the one being merged will override the existing one, ie, the trac one, allowing plugins to introduce translation errors which might make users create new ticket's for trac and not the plugin in question.
- Make use of
msgctxt. Each plugin will have it's name as it's context but this might be abusing a bit of the
msgctxt. Defenition here.
- Make use of domains. Each plugin will have it's own domain, and all localization calls must include the domain.
Now, some more problems:
msgctxtsupport is close to
Nonecurrently and it's meant for 1.0, only some minor work has been done.
msgctxtsupport is non-existant mostly because Babel does not yet support it.
- Regarding the domain option, while this is easy inside python files, it won't be that easy regarding templates; perhaps a
i18n:domainattribute should be added to genshi allowing a template to define it's domain and thus, allowing genshi to pass the domain when translating the message.
I'm tending towards the
domain option, nothing will have to change regarding Babel and changes regarding genshi shouldn't be that much.
Also, regarding plugin developers, this would just mean using another translation function other than
_ for example, and passing an extra arg; perhaps one could even do some code magic to ease this.
A new extension point would probably also be created so that plugins can register their domain and respective catalogs into trac's translator.
Change History (35)
comment:7 Changed 9 years ago by
|Priority:||normal → high|
|Severity:||normal → critical|