Christian Boos wrote:
> Christian Boos wrote:
>
>> Hello Richard,
>>
>> Thanks for pointing out the problematic places left.
>>
Sorry for the monologue, but as there's been some follow-up on this
topic, I thought I should mention them here as well. In addition, in the
last part of this message I've made a few suggestions for improving the
way we're working with the translations and the translators.
>> Richard Liao wrote:
>>
>>
>>> Hi,
>>>
>>> I'm trying to make a fully translated trac 0.12 based on the trunk(r7002).
>>> y files.
>>> e.g.
>>> trac/ticket/web_ui.py: line 308:309
>>> return tag('Ticket ', tag.em('#', ticket.id, title=title),
>>> ' (', shorten_line(summary), ') ', verb)
>>> ...
>>
>> The above will be rewritten differently:
>>
>> M_('Ticket %(ticketref)s (%(summary)s) %(verb)s'),
>> ticketref=tag.em('#', ticket.id, title=title),
>> summary=shorten_line(summary), verb=verb))
>>
So what I had in mind from the beginning but didn't quite implement in
my previous attempt, was to build translated /tags/ (i.e. Genshi builder
Elements). So instead of M/m...gettext and Markup, I should rather have
talked about tag_/t...gettext and tags:
tag_('Ticket %(ticketref)s (%(summary)s) %(verb)s'),
ticketref=tag.em('#', ticket.id, title=title),
summary=shorten_line(summary), verb=gettext(verb)))
This will produce a Genshi Element, which uses a translated string for
re-composing the list of sub-elements, eventually in a different order.
For the "verb" part, following gettext guidelines, we can use N_('...') for
marking the static strings for translation, and use gettext(var) when expanding
those translations at run-time.
See http://trac.edgewall.org/changeset/7044.
Example:
- original "en":
Ticket #38 (this is a test for [T7044] and <M_> ...) updated by cboos
- translated in "fr" (with r7046):
Le ticket #38 (this is a test for [T7044] and <M_> ...) a été
modifié par cboos
We can now apply the same technique on the various locations where
complex markup is generated (like the various TracError with markup).
> You can also see that there's a problem with the "by" which remains
> untranslated.
> Seems to be the same issue as below:
>
>
>>> 3. Since some template strings in pot file can't be displayed
>>> correctly by current Genshi ticket #129.
>>> And I want to make all template work for now. Can we make all template
>>> strings i18n-ed by hand?
>>> e.g.
>>> trac/ticket/template/ticket.html: line 139
>>> <th id="h_reporter">Reported by:</th>
>>> <th id="h_reporter">${_('Reported by:')}</th>
>>>
>>>
>>>
>> What's the problem here? A text node inside a <th>, why is that not
>> extracted?
>>
>>
>
> I'm not sure if it's related to Genshi #129.
>
And yes, that had nothing to do with Genshi #129, as this was simply an
oversight by which the template loader callback for installing the
Genshi translation filter was not set...
This is now fixed by http://trac.edgewall.org/changeset/7042 and the
text nodes in templates are now translated.
> For example, for the "by" in the timeline.html template, the source is:
>
> 41 <span class="time">${format_time(event.date,
> str('%H:%M'))}</span> ${event.render('title', context)}
> 42 <py:if test="event.author">by <span
> class="author">${format_author(event.author)}</span></py:if>
>
> and in the message.pot file, we have:
>
> #: trac/timeline/templates/timeline.html:42
> msgid "by"
>
> Should have been "by ".
>
Ok, I've seen now that this stripping was expected and normal.
> In the message.po, neither the translation for "by" nor "by " as msgid
> gets picked up when rendering.
>
And this was not due to the stripping, rather to the fact that no
template text() was ever translated, due to the lack of the Translation
filter, as explained above.
I've also looked a bit closer to the extraction topic, and it seems that
we can get rid of most of the explicit _() annotations in templates by
including the "value" attribute to the list of extracted attributes, as
those attributes need to be translated most of the time. For the few
ones for which a translation is not wanted (16 of them), we can add an
explicit xml:lang="en" attribute. This will be far less obtrusive than
having to add ${_('...')} everywhere else.
Now, on a related note but still on the very "make i18n practicable"
subject, I've started to improve the documentation related to
translations. While the level of documentation was good enough for me
(thanks Jeroen for getting me started on this!), I think more detailed
guidelines should be given to translators, so that they can more
effectively contribute.
For me, it makes absolutely no sense that translators contribute
translations without at the same time running their translated version
of Trac and verifying how good their translations are in context. A
given translation that maybe looks fine in the .po file may seem wrong
once seen in context within Trac (I verified this more than once with my
own bits of french translations).
As the translators should have a running Trac for their tests, they also
need to have at hand all the toolchain (Python, Genshi and Babel). The
only constraint being that everybody needs to have the exact /same/
versions of the tools, so that there's no variation in the msgids. This
is what I've started to document in the TracL10N page
(http://trac.edgewall.org/wiki/TracL10N?version=57) and we should
continue to do so as the toolchain evolves.
If we can agree on the above, there will be no point in continuing to
keep the trac/locale/messages.pot in the repository, neither to store
catalog updates without contributing actual translation enhancements.
This is simply useless as anyone following the guidelines above can
replay those steps and regenerate those files in exactly the same way.
Otherwise, the real changes are lost among the noise.
When there's an actual contribution made to a given messages.po file:
- there should be a first commit for the catalog update of that file
/only/ (e.g. python setup.py catalog_update -f -l fr_FR); the commit
message should be something like "automatic sync of the catalog file"; I
don't think this step could be avoided, unfortunately.
- this commit should then be followed by a second one containing the
actual translation contribution (and those are worth reviewing)
I would even suggest that we should grant the commit rights on the
appropriate catalog files directly to the translator teams, if they show
the willingness to comply to the above steps (this is up to jonas to
decide, I think).
-- Christian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
