#694: Translations scaffolding
------------------------+--------------------
Reporter: olemis | Owner: olemis
Type: task | Status: review
Priority: minor | Milestone:
Component: trac core | Version: 0.7.0
Resolution: | Keywords: i18n
------------------------+--------------------
Changes (by olemis):
* status: needinfo(review) => review
Comment:
Replying to [comment:9 SaintGermain]:
> Hi !
>
> In fact 'needinfo' is really what I had in mind, but I got mixed up and
the questions were on the mailing list instead of here.
>
back to needinfo then ... sorry ...
> So here are the questions :
>
> A) Do you want one domain per plugin or one global 'bloodhound' domain
> ? The way it works, the translation files live in the plugin
> directory, so I guess it doesn't really matter. Except if I didn't
> understand how it works and we can have one global translation file
> for all bloodhound plugin ?
>
By reading this phrase (see trac:wiki:CookBook/PluginL10N)
''providing the necessary extra information (domain) for storing and
fetching the messages from the plugin code into plugin specific message
catalogs''
I guess one domain per plugin will be needed because this is related with
setup.py message extraction and retrieval . Technically Bloodhound plugins
are independent packages , and thereby I guess that one domain for all
will lead to conflicts.
> C) As you said for 1), we would like to avoid duplicates translation
> string with Trac. How can we do that in practice ?
Our copy of Trac is independent too i.e. a separate package . No need to
do anything during extraction step . In order to reuse Trac translations
in another plugin I guess
> How can the translation mechanism know in which translation file to
> look for the translation ?
afaict that's what domains are for . In
[trac:source:trunk/trac/util/translation.py Trac trunk] I'm seeing quite a
few functions named `domain_functions` which in turn return other
(partial) functions to retrieve messages for a particular domain (i.e.
plugin package).
> Should I mark the duplicated Trac strings for translation (with _(""))
or not ?
>
I guess so , but will have to use `dngettext` , `dtgettext` , and/or
`dtngettext` in module `trac.util.translation` which support `domain`
argument .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/694#comment:11>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound issue tracker
