[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: RKWard release nearing
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2015-02-06 20:20:12
Message-ID: 20150206212012.08c2f689 () late
[Download RAW message or body]


Hi,

for the record:

On Thu, 05 Feb 2015 20:58:23 +0100
Jaap Woldringh <jjhwoldringh@ziggo.nl> wrote:
> Op 05-02-15 om 20:33 schreef Thomas Friedrichsmeier:
> > what I meant / thought was the problem, was that the string contains
> > some terms that are function / variable names and should be kept as
> > is in any translation. Not all of those were marked up, and at least
> > for the term "parameters" (in this case the name of a function
> > argument) that's clearly problematic.

This issue should be fixed with the next run of scripty. Let me know,
if you come across similar issues, elsewhere in rkward. For background:
Most of these messages have just become translatable for the first
time, and many were not originally written with i18n in mind.

> > Anyway, the translator (Jaap) got back to me, and as far as I
> > understand, the key issues he sees are something different:
> > - these translation units are too large (at least one is much larger
> >    than the example, I cited, too).
> > - they contain too much markup (as a reminder, these are
> >    HTML-formatted lists).
> >
> > Well, I can see those points. As you will have noted, these strings
> > are rather atypical for us, and that's why I did not worry about
> > this, so far. I can basically offer two possible solutions:
> >
> > 1. Split up the translation units "manually" (in the source, of
> > course).
> > 2. Automatically extract each bullet point in any list as a separate
> > translation unit.

[...]
=20
> The second point is a most welcome answer to what I
> mentioned/complained about  in my previous mail, and I am very
> satisfied that it falls into fertile ground. Thank you for this.
> I would say: any solution that keeps the messages short is welcome,
> so whether you choose possibility 1. or 2. is quite equal to me :).

Regarding this, I have done _some_ more splitting for the strings in
question, now. At least you should no longer see cases where two entire
lists are contained in one translation unit.

Splitting within a list is firmly on my TODO list, but is not entirely
trivial in our setup, so this will need a bit more time.

Regards
Thomas

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]