Translation of LibreOffice 3.6 - Plan

Hi,

Release of LibreOffice 3.6 is approaching, we need to start
translation. The amount of new or changed strings are low, compared to
LibreOffice 3.5 there are 388 in the UI and 148 in the help, 2671
words in total. Clearly, most of the work has been done under the
hood, not many new UI elements have been added, not to mention help.
On the other hand, many old, unused code lines were removed, so the
total wordcount of the whole suite is lower than ever. I think this is
good news from the localizers' point of view. :slight_smile:

My plan is the following:
1. This weekend I pull 3.5 translations from Pootle for the 3.5.5 RC1 release.
2. Then I rename LibreOffice 3.5 projects in Pootle to LibreOffice 3.6
and update the files. At the same time I import LibreOffice 3.5
templates and translations to a new LibreOffice 3.5 project. This way
we migrate all history, suggestions and whatnot from 3.5 to 3.6. At
the same time these will not be available in the new 3.5 project, but
I don't think it is a big a problem. Please work on 3.6 translations
at the first place, and only backport bugfixes to 3.5, just like
developers do.
3. LibreOffice 3.4 is dead, nobody plans to release anything from that
branch. It will be removed from Pootle.

Pootle will be down, when I do all these housekeeping tasks.

Please shout, if you disagree.

Thanks,
Andras

Hi,

<snip>

Pootle will be down, when I do all these housekeeping tasks.

do you have estimation how long it will take?

Please shout, if you disagree.

your plan was fine for me btw, I don't disagree :smiley:

Thanks,
Andras

Andika Triwidada
Indonesian translator

Several hours. Maybe a day. I'll write a mail to this list, when I
start. The timing depends on my other tasks.

Best regards,
Andras

That is the basic branching plan we use on the Sugar Labs Pootle
instance. In essence, you are freezing the old project (creating a
new project for it on Poolte) and just renaming the head project (with
all of it's commit pointers to the master branch repo). I do suggest
doing some testing on your commit links from the Poolte UI to make
sure nothing unexpected occurred during the process.

cjl
Sugar Labs Translation Team Coordinator
http://translate.sugarlabs.org/

Hi Chris,

That is the basic branching plan we use on the Sugar Labs Pootle
instance.  In essence, you are freezing the old project (creating a
new project for it on Poolte) and just renaming the head project (with
all of it's commit pointers to the master branch repo).  I do suggest
doing some testing on your commit links from the Poolte UI to make
sure nothing unexpected occurred during the process.

Many thanks for your advise, it is good to know that this method is
working somewhere else. We don't allow git commits from Pootle,
because build system does not tolerate errors in po files, so our use
case is simpler that yours.

Cheers,
Andras

Depending on how careful you are with keeping up your Pootle headers,
you may want to look into the PO file header line

Project-Id-Version:

and do something to increment it as well.

cjl