[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreoffice-l10n] Workflow based on master


Hi Stanislav, *,

On Thu, Dec 11, 2014 at 6:01 PM, Stanislav Horáček
<stanislav.horacek@gmail.com> wrote:
>
> the new workflow is a bit unclear for me. If I work only in branches, let's
> say in 4.5, does it mean that
> - changes from 4.5 branch will be ported back to master (if so, when?),

No. Nothing will be merged to master from the other branches. And
nothing will be merged from master to the other branches.

> or
> - changes in 4.5 branch will not affect the next 4.6 branch?

Yes. 4.2 translations don't affect 4.3 translations, 4.3 translations
don't affect 4.4 translations, and 4.4 translations won't affect 4.5

> Btw, it's a bit ironic that the new workflow is introduced just after
> conversion to .ui format is finally completed which should result in a
> substantially lower translation workload for 4.5:)) I would tend to continue
> with working on branches because master will bring only more (wasted)
> work...

You can think of master as translation for 4.5 There's nothing special
about master.

regular code workflow:
______________________________________________ master
\ \ \ \
\ \ \ \__libreoffice-4-5
\ \ \__libreoffice-4-4
\ \__libreoffice-4-3
\__libreoffice-4-2

All branches were once "master", and then were split up to refine stuff.

Translations were special project, as basically there was no "in
between" updates. Translations did jump from 4-2 to 4-3, from 4-3 to
4-4 without any intermediate updates in between.

Master based workflow would mean that when libreoffice-4-5 is created,
the translations of master will be copied over and reused for that,
and master then would be ongoing for libreoffice-4-6

What is benefit for translators?
No rush needed when libreoffice-4-5 is about to be released, as you
have all the time preparing the translations on master. All you have
to translate when 4-5 is about to released is the changes that are
done very late in the release-process.
Having translations for master also allows to create daily builds with
the translations more easily, so you can check translations in the
daily builds more easily.

Drawback for translators:
If you have rather incomplete translations for 4-4, then you need to
do the changes in both 4-4 and in master. Or just ignore master and
only focus on 4-4 - but then of course you have to translate all the
stuff that changed in between when the 4-5 release is split-off.
translating both shouldn't be too much work, as you can just reuse the
proposals of the translation-memory.

And all those *##* who keep ranting about the changing caps and
similar: It has been made pretty clear already that any such change
would be handled automatically with no need for retranslating. Shut
the f* up/write your stuff in other threads if you don't want to
participate in the current topic.

I'm puzzled where the perception comes from that on master you
suddenly have thousands of additional strings that you wouldn't have
to translate in the current process as well.

To ask some of the on-topic questions:
* why all languages, not just some
→ less work. It's lot easier to just process all languages at once
and don't need to think about picking individual languages.
→ that being said: You're not forced to use it. If you don't
translate on master, then you'll just have to translate all at once
shortly before release (like it's the case currently).

* master translations will only be used for the daily/snapshot builds,
not for releases. No migration from master to 4-4 or 4-3 will happen.
If you want to have the change in the release-branches, you need to
update the 4-4/4-3 translation yourself.
* master translations will be copied to 4-5 when it is due, and then
4-5 will be used for the 4.5.x release builds, and master will become
the ongoing translation for 4.6

* how frequent will there be updates
→ no more than once a moth
Translations/dialogs/etc don't change so frequently, so there won't
be changes all over the place.

* what if I don't want to use master
→ then make sure you don't actually do stuff in master, as then it
will be overriden when 4-5 is branched off
→ for those languages who chose not to make use of master, shortly
before the branch-off of 4-5 the translations of 4-4 will be copied to
master (override current master translation) and updated against
templates.
In other words: If you don't want to use master: Don't use master.
Changes you do on master will be overridden when you request copying
from 4-4. So either do any merges yourself, or don't complain
afterwards.

ciao
Christian

--
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Follow-Ups:
Re: [libreoffice-l10n] Workflow based on masterMichael Bauer <fios@akerbeltz.org>
Re: [libreoffice-l10n] Workflow based on masterMihovil Stanic <libreoffice@miho.im>
References:
[libreoffice-l10n] Workflow based on masterSophie <gautier.sophie@gmail.com>
Re: [libreoffice-l10n] Workflow based on masterSérgio Marques <smarquespt@gmail.com>
Re: [libreoffice-l10n] Workflow based on masterSophie <gautier.sophie@gmail.com>
Re: [libreoffice-l10n] Workflow based on masterStanislav Horáček <stanislav.horacek@gmail.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.