Translation status for ubuntu-docs

[Hannie Dumoleyn]

Op 26-03-12 14:46, David Planella schreef:
> Al 26/03/12 09:07, En/na Matthew East ha escrit:
>> On 26 March 2012 06:11, Timo Jyrinki<timo.jyrinki at gmail.com>  wrote:
>>> 2012/3/26 Jeremy Bicha<jbicha at ubuntu.com>:
>>>> I uploaded the potfile for ubuntu-docs tonight and opened up
>>>> translations on Launchpad for the precise branch.
>>> What about the ubuntu-docs under /ubuntu/precise/+source/ubuntu-docs -
>>> it'll be updated at the time of actual upload?
>> We don't use this, but I've amended the settings to ensure that
>> translations are shared between the two places.
>>
> Thanks Matthew. I think, as pointed out by Timo, we're all aware of the
> challenges with fuzzy strings in Launchpad, which is something that
> unfortunately will not be addressed in the near future.
>
> But unrelated to that, as mentioned other times, using message sharing
> between the source package and the upstream project will help in landing
> all the Ubuntu contributions to the upstream project, so thanks for
> setting that up.
>
> Most Ubuntu translators translate the Ubuntu source packages, which have
> got more visibility than upstreams, so I think in this regard using
> sharing is the most optimal approach.
>
>>> For future, do you think that ubuntu-docs under the Ubuntu
>>> translations should simply be not visible until the final template is
>>> uploaded? Or this current system still better?
>> This is a question for the translation coordinators rather than us,
>> I'm sure that we'll be happy to be guided by them as to how best to
>> handle this. Over the past few cycles we've been clear that we use the
>> translations in the upstream location, but that we enable translation
>> sharing on Launchpad between the package location and the upstream
>> location.
> I think there is no easy way we can mitigate the issue with fuzzy
> strings, but I'd like to hear if someone has got any ideas.
>
> In terms of hiding the template until freeze is in place, I'd personally
> recommend against that. I realize docs are a very special type of
> translation, as translations themselves are harder to do than in shorter
> strings, and as small changes in the sources mean a higher amount of
> work in retranslation than regular UI translations.
>
> The main reason why I'm against hiding templates is consistency: we show
> translation templates for all of the rest very early in the cycle, so
> that actual translations can be tested as soon as possible. A few years
> back we used to open translations relatively late in the development
> process, but at some point translators requested to have them open
> earlier, so now we tend to do it around alpha time, at the same time the
> first language packs are rolled out.
>
> So I'd prefer not to have to special-case the docs more than we're doing
> already, and have to be tracking when the template needs to be open.
>
> Barring exceptions, UI/doc freezes is the time when translators should
> be able to start doing their work safely. No translations are guaranteed
> to be stable before that, so there is always the risk of loosing work
> (well, or getting it marked as fuzzy). The truth is that we all tend to
> start translating before freezes, as generally no software is so
> unstable that all of its strings change, and we can always benefit of
> testing translations in the weekly language packs during development.
>
>> But if translators want us to make changes, or if there are things we
>> can do to make their job easier, please let us know so that we can try
>> and help.
>>
> I can think of a couple of things that could be helpful:
>
> - Keep the POT file in upstream and Ubuntu in sync. I believe this is
> something that you do already, at least at string freeze. In any case,
> as I understand it, there are some doc team contributors that are new to
> translations, so I'll reinstate it in case it can be helpful as a
> reminder: it'd be really useful to ensure that whenever there is a POT
> file update committed upstream, i.e. when you think a set of messages
> are ready to be translated, that that same template is uploaded in the
> corresponding Ubuntu source package (simply using the upload form in
> Launchpad [1], no need to do an actual source package upload). Either
> that or notifying the translators list, and then someone with
> permissions can do the .pot file upload.
>
> - Run a test server which does localized daily builds of Ubuntu docs in
> html and makes them available on a public location. I've seen something
> like that on http://37.9.231.137/build/, although it seems to build only
> the C (en-us) version. This would be very useful for localizers to test
> translations without having to wait for language pack updates. And I
> guess for documenters it would be helpful for proof-reading without
> having to do a local build.
>
> I realize the second point is more on the wishlist side. I might give
> even give it a go myself before the translation deadline, but I cannot
> promise anything.
>
> Cheers,
> David.
>
> [1]
> https://translations.launchpad.net/ubuntu/precise/+source/ubuntu-docs/+pots/ubuntu-help/+upload
>
>
>
As a translator I would like to tell you what I do:
I translate here:
https://translations.launchpad.net/ubuntu/precise/+source/ubuntu-docs/+pots/ubuntu-help/nl/+translate?start=9&batch=10&show=all&field.alternative_language=&field.alternative_language-empty-marker=1&old_show=untranslated
I also open the Oneiric version, so that I can copy and paste 
translations that have not been transferred because of minor changes in 
the English string.
I download the po file on a regular basis. Thus, I am not afraid my work 
is lost should translations no longer appear in the newly updated pot file.
I agree the ubuntu-docs are special because they have long strings. That 
is the reason I prefer to start translating as soon as possible. As you 
can see, this version is on 94% translated now.
Hannie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20120327/db87009a/attachment-0001.html>