Re: Integrate ITS Tool with gettext and Autotools

On Fri, 2015-10-09 at 13:16 +0200, Sébastien Wilmet wrote:
On Fri, Oct 09, 2015 at 11:41:59AM +0100, Emmanuele Bassi wrote:
No, not really. It's easier to see if a string is translatable if
there is an attribute called "translate" or "translatable".

There is a difference between:
<tag translatable="yes">String to translate</tag>

<tag attribute="Value to translate" another_attribute="Value" />

Jumping in at a random spot with a few random points:

1) With ITS, the default is that element content is translatable, and
attributes are not. Both can be overridden.

2) The standard attribute for local overrides is its:translate, but lots
and lots of formats allow a local translate attribute, so you can match
that with an ITS rule:

<its:translateRule selector="//*[ translate='no']" translate="no"/>

3) You can only do local overrides on elements, not attributes, because
you can't put attributes on attributes. Just one more reason why you
shouldn't put human-readable, translatable content in attribute values.

4) You can also embed specialized ITS rules in a file, if (a) your tool
supports it, and (b) other tools that consume your XML don't spit up all
over themselves as a result of it.

5) If you can determine whether something needs to be translated by
looking at stuff around it (e.g. other attribute values on the same
element), then you can write an XPath expression for it, which means you
can write an ITS rule for it.

6) Putting _ at the beginning of names is changing the names of the
elements and attributes. Your source file with the underscores isn't a
valid instance of the format, and so it can't be used in any way on its

7) If you can show me an example of an XML format that ITS can't handle,
I'll show you an example of a poorly designed XML format.

For the latter, it is convenient to prefix an attribute with an
underscore to mark it for translation. If the XML parser supports it
directly, no need for a *.in file.

And, for the latter, having an underscore is clearer to know which
strings are translated.

But if the XML parser doesn't support it, a *.in is needed if, for the
same attribute, sometimes we want to translate the value and sometimes
not. (Example: for a glade catalog file, we generally don't want to
translate GObject class names).

Also, sometimes we don't want to
translate something, although the attribute is marked for translation.

That's… I can't fathom the process. If something should not be
translated, don't mark it for translation.

It was a misunderstanding.

If the ITS rule says that 'bar' attributes for tag 'foo' are marked for
translation, then all 'bar' values will be extracted in the *.pot file.

desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]