← Back to team overview

schooltool-developers team mailing list archive

Re: Mixing i18n domains and message factories

 

2012/7/31 Douglas Cerna <douglascerna@xxxxxxxxx>:
> Hey everybody.
>
> While working in the new CanDo, I've started to pay attention to i18n. Since CanDo depends on multiple packages, I was wondering what you guys think of mixing i18n domains and message factories across the code.
>
> I mean, for example, I know the words/messages "Grade" and "Score" are also present in the gradebook. And we already have several translations for it there. Same with "Done" or "Add" in core, etc.

Yes, there are more and more duplicate messages across modules. A few
times I have copied translations of duplicate strings from core to
other modules (using msgmerge -C), but this only increases translation
percentage, the strings are still duplicate, and if changed in core,
they will not change elsewhere.

> IMHO, i18n:domains are really easy to combine in ZPT, since you can attach it to one particular tag.

Yes, I have done that in a small number of places.

> However, it becomes a little more work in Python code, because you need to use message factories, and the '_' shortcut is usually pointing to CanDo's message factory. If I'd like to use the 'Add' translation from core in a CanDo module, I'd need to:
>
> from schooltool.common import SchoolToolMessage
> ...
> button_label = SchoolToolMessage('Add')
> ...
>
> which looks a bit heavy.

This is correct, and works.

> I think we could have alternatives, but they would rely on developers knowledge of the current messages, like:
>
> from schooltool.common import SchoolToolMessage as _core
> ...
> button_label = _core('Add')
> ...
>
> or:
>
> from schooltool.gradebook import GradebookMessage as _gradebook
> ...
> header = _gradebook('Score')
> ...
>
> and so on. I think the i18n message extractor would ignore those, right?

That's possible too and is shorter.

The extractor only pays attention to the domain of _ at the module
level. If you redefined _ in local scope, the different domain would
not be noticed and the string will be extracted.

So yes, _gradebook or GradebookMessage will not be extracted and
that's what we want.

> And maybe we could generate an automatic list of "message id" -> "SchoolTool package" so we all know if a message is available and where it is. It could help us minimize the number of strings to translate.

I think "minimize the number of strings" would be a separate task and
many such strings would be eliminated at once.

To check if a string is available somewhere is a simple grep:

  $ grep -l '^msgid "Message"' schooltool/src/schooltool/locales/*.pot
*/src/schooltool/*/locales/*.pot

To generate an automatic list of msgid -> package mapping... That
would be a directory with all the *.pot files, and do the same as
above:

  $ mkdir strings
  $ cp schooltool/src/schooltool/locales/*.pot
*/src/schooltool/*/locales/*.pot strings
  $ grep -l '^msgid "Message"' *.pot

To find common strings in two templates there is a msgcomm utility
(from gettext):

  $ msgcomm  --more-than 1 \
        schooltool/src/schooltool/locales/schooltool.pot \
        schooltool.gradebook/src/schooltool/gradebook/locales/schooltool.gradebook.pot

The result of above command shows that there are 53 strings in
gradebook that could be eliminated.

> What do you guys think? Is it worth? Am I making a mountain out of a molehill?

I think it is worth doing, because the new modules would be better
translated. Currently journal or intervention sees much less
translator activity than core.

There are other ways to share translations. Create widgets or template
macros that can be reused. Extend interfaces or forms from core and
only define new attributes. The duplication of strings is often the
result of copy-pasting code snippets. Of course "Teacher" can be a
table column in one page and a menu item in another, so this is not
always possible. But "Cancel" most likely is the right-most button at
the bottom of the form...

There are many strings that could be eliminated. Some come from old
skin. Some differ only slightly (e.g. "Title" and "Title:"). Some have
an additional variable, e.g. "Sections" and "Sections for
${schoolyear}".

Reducing number of total strings and avoiding changes leads to more
complete translations.

-- 
Gediminas


References