help requested in adding translation comments

Bug #168838 reported by Xaviconde-users on 2007-08-18
6
Affects Status Importance Assigned to Milestone
Inkscape
Low
Unassigned

Bug Description

Hi!

Based on a discussion on inkscape-translators list, we think some terms
need additional comments for helping translators on our task. The following
thread shows some of them, as well as some explanations by translators
themselves:

http://sourceforge.net/mailarchive/forum.php?thread_name=5eb2c9220708150444
y63ade4cdmc31594a6c59b2a7d%40mail.gmail.com&forum_name=inkscape-translator

We think that this additional info should be added to the PO files, since
it is a great help for improving the correctness of our translations.

Many thanks in advance

Originator: NO

Please create a patch adding these comments to the .cpp files - that's
where the PO files take them from. When ready, submit the patch to the
patch tracker. Thanks!

Clytie Siddall (clytie) wrote :

Originator: NO

I'll add the msgctxt information here, as well.

msgctxt is the context feature added in recent versions of gettext. It
enables the developer to add contextual information, without mixing it up
with the string headers. It allows translators to use these strings more
effectively in translation memory. We hope it will encourage more
developers to follow Inkscape's example by providing context for messages
needing translation. :)

A summary:

 - PO files can now contain messages constrained to a certain context.
    Most often such a context is a menu, dialog or panel identification.
    The syntax in the PO file is
      msgctxt "context"
      msgid "original"
      msgstr "translation"
  - The xgettext program can be told through the --keyword flag which
    function/macro argument has the role of a context.
  - The (non-public) include file gettext.h defines macros pgettext,
dpgettext
    etc. that take a context argument.
  For more information, see the node "Contexts" in the manual.

http://www.gnu.org/software/gettext/manual/

I would also suggest that you use another newer gettext feature,
previous-msgid. This feature allows translators to diff between different
versions of strings. It is particularly useful when a string is complex or
long and detailed. When a string has changed the PO file looks like this
(simple and brief example):

#, string header
msgid-previous "This is the old string"
msgid "This is the new string"
msgstr "This is the old string translated"

The translation editor can highlight the changed words, in this case,
"old" and "new" in msgid-previous and msgid. It's a big help in updating
files. Without msgid-previous, when you notice a long help screen has been
changed (fuzzy), it actually takes less time to translate the whole thing
again, than it does to pick through it and try to work out what has
changed. So msgid-previous saves us translation time, and ensures we focus
on what has actually changed in the string.

I hope Inkscape will take advantage of these newer features in gettext. :)

Clytie Siddall (clytie) wrote :

Originator: NO

I hope you're requesting Inkscape developers create patches with the
contextual information. They're the ones who have created the strings, and
thus understand what they actually mean. Context is a developer action. We
then respond to that action by creating accurate translations of those
strings.

Originator: NO

ok, if you translators request help from developers in disambiguation,
then i'm reopening it as a bug

Luca Bruno (lucab) wrote :

I did a bit of digging about msgid-previous and found that this should first supported by intltool, so that we can turn it on at make time.

Changed in inkscape:
importance: Undecided → Low
jazzynico (jazzynico) wrote :

intltool-update doesn't seem to support previous msgid (at least with 0.50.2 on Debian stable).
But users can user the --previous flag when updating their po files with msgmerge:
# msgmerge --previous -Uv def.po inkscape.pot

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers