Hi;

On 9 October 2015 at 11:11, Sébastien Wilmet <[email protected]> wrote:
> On Thu, Oct 08, 2015 at 06:51:59PM +0900, Daiki Ueno wrote:
>> > To mark XML attributes as translatable, a common thing to do is to
>> > prefix them with an underscore. Intltool supports that, but not gettext
>> > AFAIK. If the ITS branch supports that, it would cover lots of simple
>> > cases.
>>
>> It sounds to me one step back, since it typically involves unnecessary
>> intermediate files (*.in, *.in.in, ...) or a special treatment of
>> underscores in your XML parser.  On the other hand, it can be easily
>> written as an ITS rule:
>>
>>   <its:translateRule selector="//*[starts-with(name(.), '_')]" 
>> translate="yes"/>
>
> With an underscore, when reading the XML file it's clearer to know what
> is translated and what is not.

No, not really. It's easier to see if a string is translatable if
there is an attribute called "translate" or "translatable".

The leading underscore is a source of bugs and build failure, and
always has been, because humans, scripts, and tools manage to forget
it on a regular basis — and have been doing so for the past 10 years
since we had to deal with this particular brand of cleverness that
intltool brough upon us.

The leading underscore awfulness is also directly responsible for
intermediate .in.in files, which contribute more than most to
distcheck failures; to things like parallel make breaking because of
missing dependencies; and to weird entries in the POTFILES file.

Use attributes to determine if the contents of an XML element is
translatable. It's simple, it's extensible, and it does not break
other assumptions.

> 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.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to