Workflow based on master

Hi all,

Another follow-up on the discussion we had, who would be interested to
have a translation workflow based on master?

To understand, that would mean that a new project named 'master' will be
created on Pootle. Once a month, Cloph will extract the strings from
Pootle to the source code. The main translation work will happen on this
project with a timeframe of about 6 month to do the work. When a new
version is branched off, the master translations would be used to create
a release branch project.

Note that if you fix something in master project, it won't automatically
end up in the existing release branch-translations, you will have to fix
it these projects too. But the rule of no addition of strings will still
apply for developers, so there will be few changes and minor corrections
here.

What is your opinion on that?
Cheers
Sophie

I have same ability to translate com-central on mozilla repositories, but I never use it. It's too unstable and a lot of changes.
If someone thinks it will be useful for him, you can implement it, but I know I won't use it.

Best regards,
Mihovil

3.12.2014. u 18:27, Sophie je napisao/la:

Hi Sophie

Hi all,

(snip)

What is your opinion on that?
Cheers
Sophie

I am for it. +1

For me (Portuguese) it´s fine as is. I know that from time to time. we have
a lot of work. But I prefer that way. Master strings, as Mihovil said, has
many changes all the time. I prefer to do the work one time only.

Regards

Hi all,

So Cloph will create a master project for all the languages. You can
choose where you want to translate, on master or on the next branch
(4.5.0) when it will be created. Let see if it is better or not in our
project :slight_smile:

Cheers
Sophie

I think it is a good idea, let's try it.

I have to check it and understand if it works for us.

Ciao

Hi,

So Cloph will create a master project for all the languages. You can
choose where you want to translate, on master or on the next branch
(4.5.0) when it will be created. Let see if it is better or not in our
project :slight_smile:

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?), or
- changes in 4.5 branch will not affect the next 4.6 branch?

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...

Best regards,
Stanislav

P. S.: Any news about Amagama update? It would be extremely handy for current help translation.

Hi,

So Cloph will create a master project for all the languages. You can
choose where you want to translate, on master or on the next branch
(4.5.0) when it will be created. Let see if it is better or not in our
project :slight_smile:

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?), or
- changes in 4.5 branch will not affect the next 4.6 branch?

It will be exactly as it is now for the work on 4.4, the template will
be updated in 4.6 branch between beta1 and RC1. 4.5 and 4.6 branches
will be maintained independently, just like now for 4.3 and 4.4.

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...

Did you suggest the idea then :wink: I didn't have it either :slight_smile:

Best regards,
Stanislav

P. S.: Any news about Amagama update? It would be extremely handy for
current help translation.

Unfortunately Dwayne was traveling. I'll ping him again tomorrow. And
yes, it would make a lot of people happy.
Cheers
Sophie

Dne 11.12.2014 v 18:44 Sophie napsal(a):

Hi,

So Cloph will create a master project for all the languages. You can
choose where you want to translate, on master or on the next branch
(4.5.0) when it will be created. Let see if it is better or not in our
project :slight_smile:

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?), or
- changes in 4.5 branch will not affect the next 4.6 branch?

It will be exactly as it is now for the work on 4.4, the template will
be updated in 4.6 branch between beta1 and RC1. 4.5 and 4.6 branches
will be maintained independently, just like now for 4.3 and 4.4.

Sorry, I don't get it. Now: 4.4 was created and translations from 4.3 appeared there.
Future: Which translations will appear in 4.5 when it is created - from 4.4 or from master? Translations of the same strings can differ between them.

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...

Did you suggest the idea then :wink: I didn't have it either :slight_smile:

I was absolutely happy with working on branches, this was not complaint, just a side note:))

P. S.: Any news about Amagama update? It would be extremely handy for
current help translation.

Unfortunately Dwayne was traveling. I'll ping him again tomorrow. And
yes, it would make a lot of people happy.
Cheers
Sophie

OK, thanks!

Stanislav

Dne 11.12.2014 v 18:44 Sophie napsal(a):

Hi,

So Cloph will create a master project for all the languages. You can

choose where you want to translate, on master or on the next branch
(4.5.0) when it will be created. Let see if it is better or not in our
project :slight_smile:

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?),
or
- changes in 4.5 branch will not affect the next 4.6 branch?

It will be exactly as it is now for the work on 4.4, the template will
be updated in 4.6 branch between beta1 and RC1. 4.5 and 4.6 branches
will be maintained independently, just like now for 4.3 and 4.4.

Sorry, I don't get it. Now: 4.4 was created and translations from 4.3
appeared there.
Future: Which translations will appear in 4.5 when it is created - from
4.4 or from master? Translations of the same strings can differ between
them.

Yes me too. Shopie´s explanation make it even more difficult to understand
the procedure.

Since I do my own compilation, for me it will mean that all strings will
be updated periodically in pootle under the "master" branch. So I will
get the updates once in a day/week/month, for example.

The number of strings on a monthly basis are expected to be lower than
on updated once in a half-year for a major release.

Those who will translate the master branch can check the results with
the nighly builds.

when it comes to branch for a new release, a snapshot of the master
translation will be taken and named release X.Y. Then all translation of
the release follows. Like with developers, a fix in a translation on a
branch shall be fixed also in master branch.

This scheme does not means we will get less work, it means we will get
more time to translate a big, hopefully incremental, chuck of new strings.

That's great, people which use master for translation will be our canary birds!
If devs start changing caps, ', ... etc, please warn us so we can spam them. :slight_smile:

12.12.2014 u 11:54, Olivier Hallot je napisao/la:

Dne 12.12.2014 v 11:54 Olivier Hallot napsal(a):

Sorry, I don't get it. Now: 4.4 was created and translations from 4.3

appeared there.
Future: Which translations will appear in 4.5 when it is created - from
4.4 or from master? Translations of the same strings can differ between
them.

Yes me too. Shopie´s explanation make it even more difficult to understand
the procedure.

Since I do my own compilation, for me it will mean that all strings will
be updated periodically in pootle under the "master" branch. So I will
get the updates once in a day/week/month, for example.

The number of strings on a monthly basis are expected to be lower than
on updated once in a half-year for a major release.

Those who will translate the master branch can check the results with
the nighly builds.

when it comes to branch for a new release, a snapshot of the master
translation will be taken and named release X.Y. Then all translation of
the release follows. Like with developers, a fix in a translation on a
branch shall be fixed also in master branch.

This workflow means that everyone is forced to work on master - otherwise it is needed to translate the same strings again and again in branches which makes no sense.

And that's why I am confused - because we were assured that it will be possible to choose between working on master and working on branches.

This scheme does not means we will get less work, it means we will get
more time to translate a big, hopefully incremental, chuck of new strings.

Keeping master updated always means more work and it is the reason why I think that each team should decide if they want to use master or not.

Best regards,
Stanislav

Could someone please explain what's currently proposed in terms that avoid terms like 'master' There are a lot of localizers who work on the basis of 'I see a string, I translate it' who aren't necessarily familiar with masters and branches and whatnots but since this will affect localizers, this should be explained in simple terms. A lot of the people I support off-list wouldn't be able to make that choice knowing what they're getting themselves in for.

Or let me rephrase that as a question. Does the current proposal
- minimize retranslation work by not presenting localizer with hundreds of retranslations when the English source goes from a formatted something to an unformatted something or back again?
- present the localizers with stable strings i.e. strings which are likely in their final form for use in the UI?

Michael

Sgrìobh Stanislav Horáček na leanas 12/12/2014 aig 11:45:

12.12.2014 u 12:45, Stanislav Horáček je napisao/la:

This workflow means that everyone is forced to work on master - otherwise it is needed to translate the same strings again and again in branches which makes no sense.

And that's why I am confused - because we were assured that it will be possible to choose between working on master and working on branches.

In my head is like this:
- Master is updated every day in pootle, but only source strings. If you translate something, it will stick, but only if dev doesn't change source string again (which is possible since it's work in progress).
- When 6 months passes, everything is moved to "stable" branch, including translations.

This is where is gets tricky. How do you transfer translations between master and stable?
What if I updated some translations only in stable? Do they get backported to master?

Anyway, as long as they don't delete my translations in stable, I don't have anything against master branch, but I will probably not use it.

Mihovil

12.12.2014 u 12:53, Michael Bauer je napisao/la:

- minimize retranslation work by not presenting localizer with hundreds of retranslations when the English source goes from a formatted something to an unformatted something or back again?

No. But you will see it before anyone else. :slight_smile:

- present the localizers with stable strings i.e. strings which are likely in their final form for use in the UI?

No, quite oposite. More unstable strings since master is "work is progress" branch, lots of changes.

Then what on earth do we gain by this 'new' approach? Is the idea that some very active locales like German will spot problems on master fast and maybe raise the issue before it hits stable strings?

Michael

Sgrìobh Mihovil Stanic na leanas 12/12/2014 aig 11:58:

12.12.2014 u 12:45, Stanislav Horáček je napisao/la:

This workflow means that everyone is forced to work on master - otherwise
it is needed to translate the same strings again and again in branches
which makes no sense.

And that's why I am confused - because we were assured that it will be
possible to choose between working on master and working on branches.

In my head is like this:
- Master is updated every day in pootle, but only source strings. If you
translate something, it will stick, but only if dev doesn't change source
string again (which is possible since it's work in progress).
- When 6 months passes, everything is moved to "stable" branch, including
translations.

This is where is gets tricky. How do you transfer translations between
master and stable?

What if I updated some translations only in stable? Do they get backported

to master?

That is exactly my problem. How do they get merged?

Let´s see. I don´t want to work on master so I don´t. But between releases,
let´s assume 4.5 and 4.4, I´m working on 4.4 only. But there is a master
project in pootle. So if 4.5 is built upon master, changes I´ve made in 4.4
branch will not be in 4.5. And I will have to do it all and over again? But
I don´t keep a journal with changed strings and I supposed not many people
do. And even if I manage to keep a journal, which i don´t want,isn´t this
worse than what we have right now?

On the other hand, if changes made on 4.4 branch make it their way to
master and back to 4.5 branch that´s ok.

But, to make it even more complicated, what happens if we work on master
and 4.4 branch? I change on master some strings that are from 4.4 branch
and don´t update 4.4? When strings from 4.4 make their way to master
(assuming 4.4->master->4.5), strings changed in master will be replaced by
ones in 4.4 or won´t they. I don´t know, it´s very unclear to me.

Dne 12.12.2014 v 11:54 Olivier Hallot napsal(a):

Sorry, I don't get it. Now: 4.4 was created and translations from 4.3

appeared there.
Future: Which translations will appear in 4.5 when it is created - from
4.4 or from master? Translations of the same strings can differ between
them.

Yes me too. Shopie´s explanation make it even more difficult to
understand
the procedure.

Since I do my own compilation, for me it will mean that all strings will
be updated periodically in pootle under the "master" branch. So I will
get the updates once in a day/week/month, for example.

The number of strings on a monthly basis are expected to be lower than
on updated once in a half-year for a major release.

Those who will translate the master branch can check the results with
the nighly builds.

when it comes to branch for a new release, a snapshot of the master
translation will be taken and named release X.Y. Then all translation of
the release follows. Like with developers, a fix in a translation on a
branch shall be fixed also in master branch.

This workflow means that everyone is forced to work on master - otherwise
it is needed to translate the same strings again and again in branches
which makes no sense.

And that's why I am confused - because we were assured that it will be
possible to choose between working on master and working on branches.

This scheme does not means we will get less work, it means we will get
more time to translate a big, hopefully incremental, chuck of new strings.

Keeping master updated always means more work and it is the reason why I
think that each team should decide if they want to use master or not.

I tottaly agree with you. In fact, a while ago Shopie asked us if we wanted
a master branch for our language. And my reply was very clear. NO.

So why the hell someone decided to ignore what I and others told her?

Where is the need to create a master branch for ALL languages even If we
don´t want it? That will give more work to Cloph to create it and probably
Christian will also have more work this way. And from what I can understand
from this messages is that most of the translators don´t want a master
branch.

12.12.2014 u 15:04, Sérgio Marques je napisao/la:

So why the hell someone decided to ignore what I and others told her?

Because you should be against something upfront. If it doesn't affect your current workflow, why do you care?
As I understood it, you will have option to use it or not use it.
Don't use it.

Mihovil