Re: [Po4a-devel] Bug#646173: Typos found while translating the po4a documentation into German
by David Prévot
Hi Helge, the po4a upstream developers list,
Le 02/11/2011 10:15, Helge Kreutzmann a écrit :
> First a typo/question:
> "The configuration file consists of several sections, general, XML/XSL "
> "support, POD support and HTML support."
(that's a po4a-build(1) string)
> Looks like "general" is spelled with a lower case "g", however in the
> next string:;
> "General includes the name and location of the po4a config file (probably "
> "best to leave this as <filename>po4a.config</filename>), the po directory "
If I understood correctly “general” is a just word, “global” would have
fit here as well, it's just the “common” part of the po4a-build.conf(5)
file. So I don't think there is any typo here, but Neil should be able
to enlighten us here.
> -"This define a module alias named B<test>, based on the B<man> module, with "
> +"This defines a module alias named B<test>, based on the B<man> module, with "
Fixed.
> The next one I only mention once, but I saw it several times (e.g. in
> doc/po4a-build.conf.5.pod:35 and lib/Locale/Po4a/Sgml.pm:47 as well):
> -msgid "Extra options for B<msgmerge>."
> +msgid "Extra options for B<msgmerge>(1)."
It's not fundamentally an error, I don't even know if we want to fix it,
the po4a upstream developers list CCed to gather more opinions.
> Btw. you use different markup for denoting programs, e.g. in
> po4a-translate:30 you use L<>.
It's a POD feature, see perlpod(1) (not all manual shipped in po4a have
a POD source).
> I'm not sure if that can be unfuzzied and also you might consider
> using the same phrase (albeit needing the same fix) from
> po4a-updatepo:92? to remove one almost duplicate string.
> -msgid "List the documentation format understood by po4a."
> +msgid "List the documentation formats understood by po4a."
> See also above:
> -msgid "List the documentation format handled by po4a."
> +msgid "List the documentation formats handled by po4a."
Plural was already used in the (few) translated languages I was able to
understand, so I also unfuzzyed all of them (anyway, grammar rules vary
among language). Since “understood” was already used in po4a-gettextize,
po4a-normalize, and po4a-translate, I fixed po4a-updatepo to use the
same wording (s/handled/understood).
> This one I'm not 100% sure, please check:
> -"provided PO file should be the translation of the POT file which were "
> +"provided PO file should be the translation of the POT file which was "
Agreed, unfuzzyed too.
> -"the addition of a new module boring, to make sure the documentation is "
> +"the addition of a new module boring, because you had to make sure the documentation is "
I'm not sure if the original sentence of Locale::Po4a::Chooser(3) is
wrong, even if yours sounds better. The rest of the string might need
fixing too, more comments are welcome.
> As long as this bug is open, I can continue filing the typos found
> here, how would you like to proceed in the future?
Fine for me, I think other active po4a contributors are following the
BTS too, I just CCed the po4a upstream developers list to make sure of
that. For future typos, providing an actual patch[es serie] one could
review and acknowledge directly would be even more welcome, you may send
them directly to <po4a-devel(a)lists.alioth.debian.org> (it's a low
traffic list you may consider subscribing to).
Regards
David
12 years, 11 months
- 2
- 2
CR-LF characters in docbook (and xml in general)
by Bob Jolliffe
Hello
I have a problem with parsing message strings in docbook para
elements. Many authors present the text in these elements in multiple
lines eg.
<para>This is a long paragraph which spans
multiple lines. I would like it to be presented
as a po message string to be translated</para>
This is handled perfectly well by po4a-gettextize for most cases.
Unfortunately some authors are using editors which represent the
newline as a \r\n sequence instead of just \n.
The proper behaviour of an xml parser according to the spec
(http://www.w3.org/TR/REC-xml/#sec-line-ends) is to simply swallow
those redundant \r characters. Unfortunately the po4a tools are
passing them through to the po files which is confusing for the
translator when using tools like pootle. The translator doesn't know
whether the \r characters are required, whether they are significant
etc.
I am not sure exactly how the XML module is working, but would it be a
complicated fix to request that the module processes the XML by
swallowing the \r characters as per the spec?
It is not critical as it is certainly simple enough to pre-process the
input files with tr or something similar, but it would be nice (and
make the workflow easier) if the xml parser did this by default.
Regards
Bob
13 years
- 1
- 0
- ← Newer
- 1
- Older →