Re: gnome-devel-docs on developer.gnome.org

2014-05-26 Thread Ask Hjorth Larsen
Hello

Daniel: Sorry for the late reply.  gtxml presently assumes that
strings "by default" should be valid xml, which was not the case in
previous revisions.  This probably explains the difference.  Back in
the days I don't think there were translator_credits strings in the
docs, so this change could be made without getting into trouble -
something which clearly isn't the case anymore.  It's a simple matter
to recognize the translator credits strings though.

So in general: gtxml is not only meant for the GNOME docs, it's
supposed to be a bit more generalist.  An option or mode could be
written (without much trouble at all) specifically for GNOME docs to
weed out known false positives.  If a powerful being confirms that a
gtxml check is desired for the GNOME docs (and by powerful I mean
someone who has the rights/expertise/etc. to get things to run on the
server) then I will be glad to write a special mode.

Regarding the placeholders: I don't know how to completely generally
recognize a placeholder tag.  I.e. whether, upon seeing a tag, it has
to exist in the translation as well or not.  For a placeholder the
answer is yes.  For another tag the answer is typically no.

Best regards
Ask

2014-05-13 11:33 GMT+02:00 Daniel Mustieles García :
> As I've commented to Christian Kirbach in private mail, when I generated the
> reports before a new stable release, I didn't get this kind of errors, so
> I'm really confused about what is happening. The only difference I see is
> that I used to generate them under Ubuntu 12, and now I'm using Debian...
> maybe it's due to Python versions? I'm installing a virtual machine to
> investigate it...
>
> Anyway... simply ignoring the translator-credits line would be enough to
> have good reports. Media links are not used at all in the PO files, so it
> doesn't matter how you translate them; about placeholders, they should
> placed in the right place, as they often indicate the kind of license or the
> name of the program, so they should be, at least, the same in the translated
> and in the original string (but not in the same order).
>
> Thanks to all of you for your comments (and special thanks to Ask for taking
> care of this :) )
>
> Cheers!
>
>
> 2014-05-09 19:44 GMT+02:00 Rūdolfs Mazurs :
>
>> Pk, 2014.05.09. 16:51 +, Rafael Ferreira rakstīja:
>> > If someone that knows python3 could patch pyg3t to fix this, I think
>> > it would be a great tool for this XML validation... Someone?
>>
>> specifically in "translator-credits" strings, the e-mail is often put in
>> angle brackets, which is not a valid XML.
>>
>> If the translator-credits string is parsed with XML, that IS a bug.
>> Otherwise just skip the translator-credits string in the xml check.
>>
>> --
>> Rūdolfs Mazurs 
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


String additions to 'libgdata.master'

2014-05-26 Thread GNOME Status Pages
This is an automatic notification from status generation scripts on:
http://l10n.gnome.org.

There have been following string additions to module 'libgdata.master':

+ "Property '%s' does not hold an image"

Note that this doesn't directly indicate a string freeze break, but it
might be worth investigating.
http://git.gnome.org/browse/libgdata/log/?h=master
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n