Re: [l10n] Manual translation issues
On Wed, Sep 15, 2004 at 01:36:08AM +0200, Frans Pop wrote:
> Looks like your knowledge of xml and the tools is better than mine.
> Maybe we can work something out together faster than I thought :-)
We'll see ;) I just hope to make everything _usable_ for the translators
and maintainable for the admins....
> > Can we restructure that one somehow? Split in two, for example, this
> > would solve the problem.
> Yes, that works. I have split the file into bookinfo.xml and
> preface.xml. I will try to check all .xml files for the same kind of
> errors.
Great, one problem solved :)
> Hmm. The strange stuff I saw was in the partman.nl.po I created. The
> .pot file looks much better :-)
> <snip>
> <informalexample><screen>&POXML_LINEFEED;&POXML_SPACE;&POXML_SPACE;IDE1&POXML_SPACE;master&POXML_SPACE;
> (hda)&POXML_SPACE;-&POXML_SPACE;6.4&POXML_SPACE;GB&POXML_SPACE;WDC&POXML_SPACE;AC36400L&POXML_LINEFEED;
> </snip>
> Looks like there may be a difference between split2po and xml2pot. Any
> ideas?
Well, yes, kind of. I tried it myself and it's really a problem with
split2po. I'm not sure whether this is a bug or a feature, bugs.kde.org
shows no entries, so I suppose it's the way it should go. poxml source
(all hail the open source! ;)) has a function calles escapeLiterals, which
does this:
contents.replace(QRegExp("\n"), "&POXML_LINEFEED;");
contents.replace(QRegExp("<"), "&POXML_LT;");
contents.replace(QRegExp(">"), "&POXML_GT;");
contents.replace(QRegExp("\t"), " ");
contents.replace(QRegExp(" "), "&POXML_SPACE;");
And there is also a function calles descapeLiterals, which does the exact
opposite. xml2pot does descaping before it output the strings, split2po
does not. Don't ask me why ;)
However, we can help ;) I could get reasonable results using a pipe:
| sed 's/&POXML_LINEFEED;/\\n\"\n\"/g' | sed 's/&POXML_SPACE;/\ /g'
So split2po might be usable after all.
> > > split2po: - preface.xml: I had added a <para> in the Dutch .xml
> > > explaning that the translation is Work in progress;
> > Shouldn't this be a conditional <para> in every translation, which
> > would get disabled on some occasion?
> Can you suggest something?
<para condition="translation">Note from the translator: as you might
notice....</para>
<para condition="work_in_progress">This is work in progress!</para>
This would require some small structural changes to the build system, such as
including language-options the same way arch-options are included in
buildone.sh. Then every translation except for the english one, would get
an option "translation" and also "work_in_progress" for known incomplete
translations.
> The problem is you would probably need some
> kind of 'placeholder <para>' in the English original that would not be
> included in the build. Also, we would probably want to limit this to
> some places.
This would remove some flexibility for the translators, but I think the
manual should be consistent and thus there should be defined places for
such translators' commentaries.
> > <BTW> There is some arch-dependant mess in buildone.sh (at least in
> > SVN) which should be best split out of there and updated. At least the
> > kernel versions are not right. </BTW>
> Suggestions welcome. (It is being updated in general, but there have
> been quite a few kernel changes recently.)
1. mkdir build/arch
2. Put all options from "case" into build/arch/$arch
3. Do an . arch/$arch inside of buildone.sh.
4. The same should be done with languages (build/lang/$lang). It would
also be nice, if install.$lang.xml could get auto-generated - there is no
real necessity to have it multiple times.
> > > - administrivia/contributors.xml: I had resorted the languages in
> > > Dutch.
> > I think this is actually the task of the appropriate xsl-stylesheet,
> > if I'm not mistaken. However, my xsl experience and knowledge is very
> > rudimentary.
> Don't know how that would work as it would mean sorting inside a table.
According to http://www.developer.com/xml/print.php/600721 this can work.
However, I'll have to peak into our xsl-files to see if it possible to
insert that code somewhere.
> For now, I'll just reorder the languages in my translation to the
> original sequence. Again, not an error, just something to watch out
> for.
This is the kind of automation which would help both users and
translators. I hope xsltproc _can_ figure out how to sort
locale-dependantly.... ;)
> > Are the "big structural changes" coming to the manual soon, or is it
> > almost finalized? I though, I've seen mentioning of boot-floppies
> > somewhere...
> Depends on how much people want to work on the manual. See also my mail
> [1]. [1] http://lists.debian.org/debian-boot/2004/09/msg00813.html
So today you're making some changes, neat ;) BTW, I'm thinking about
coming to Oldenburg too, I'm not _that_ far away.
--
Nikolai Prokoschenko
nikolai@prokoschenko.de / Jabber: pronik@jabber.org
Reply to: