Workflow of translations if adding text to views

[JuliusR]

At the moment I am working on a better user interface for the creation of deliveries [1]. For that, I probably need to add some new texts to the views.

Which workflow do you propose for providing translations for all languages? I would be able to provide correct german texts and more or less suitable english translations. Should I suggest english translations or is it more work to check all the new expressions then?

I also wonder if it is better to first experiment with single-language (e.g. english) views and to move the expressions to the config file after all discussions are finished and changes have been made.

[1] https://github.com/foodcoops/foodsoft/issues/103

[wvengen]

Hi Julius,

Good point. I've been thinking about this.
Perhaps something workable might be:

• Master needs to be fully i18n, synced with localeapp
• Work on features in a branch, use text in templates if you like. Pull request needs to include i18n.
• On accepting pull request in foodcoops/foodsoft, make new strings appear in localeapp.

The last step can be tricky. If it's just a handful, you can add them manually (localeapp website or cli `localeapp`). If it's more, first *pull* translations, *review* changes, *commit* them to master. Then, *merge* pull request, and *push* locale file(s) to localeapp. Then *pull* again from localeapp - if there are order or formatting changes, add them in a single commit (so that a localeapp roundtrip doesn't induce a change in the locale files).

What about that?

Cheers,
- Willem

On 13-06-13 10:28, JuliusR [via foodsoft] wrote:

At the moment I am working on a better user interface for the creation of deliveries [1]. For that, I probably need to add some new texts to the views.

Which workflow do you propose for providing translations for all languages? I would be able to provide correct german texts and more or less suitable english translations. Should I suggest english translations or is it more work to check all the new expressions then?

I also wonder if it is better to first experiment with single-language (e.g. english) views and to move the expressions to the config file after all discussions are finished and changes have been made.

[1] https://github.com/foodcoops/foodsoft/issues/103

[JuliusRapp]

Hi Willem,

thanks for your answer. I hope I understand you correctly - the last part was a bit too fast for me as a git newbie:

1. work in a feature branch (e.g. improve-deliveries) in a different repository (e.g. foodcoop-rostock) with plain text in views
2. discuss and modify until structure is fine
3. then externalize text strings; provide at least one language
4. pull request to branch `improve-deliveries` in `foodcoops`
5. translate to other languages with localeapp
6. pull request for merging feature branch to master

Is that correct?

Julius

Am 13.06.2013 12:23, schrieb wvengen [via foodsoft]:

Hi Julius,

Good point. I've been thinking about this.
Perhaps something workable might be:

• Master needs to be fully i18n, synced with localeapp
• Work on features in a branch, use text in templates if you like. Pull request needs to include i18n.
• On accepting pull request in foodcoops/foodsoft, make new strings appear in localeapp.

The last step can be tricky. If it's just a handful, you can add them manually (localeapp website or cli `localeapp`). If it's more, first *pull* translations, *review* changes, *commit* them to master. Then, *merge* pull request, and *push* locale file(s) to localeapp. Then *pull* again from localeapp - if there are order or formatting changes, add them in a single commit (so that a localeapp roundtrip doesn't induce a change in the locale files).

What about that?

Cheers,
- Willem

On 13-06-13 10:28, JuliusR [via foodsoft] wrote:

At the moment I am working on a better user interface for the creation of deliveries [1]. For that, I probably need to add some new texts to the views.

Which workflow do you propose for providing translations for all languages? I would be able to provide correct german texts and more or less suitable english translations. Should I suggest english translations or is it more work to check all the new expressions then?

I also wonder if it is better to first experiment with single-language (e.g. english) views and to move the expressions to the config file after all discussions are finished and changes have been made.

[1] https://github.com/foodcoops/foodsoft/issues/103

---

If you reply to this email, your message will be added to the discussion below:

http://foodsoft.51229.x6.nabble.com/Workflow-of-translations-if-adding-text-to-views-tp58p59.html

To start a new topic under foodsoft-dev, email [hidden email]
To unsubscribe from foodsoft-dev, click here.
NAML

[wvengen]

Hi Julius,

It was fast - and it's a combination of git and localeapp. I'd like to spread the work over different people as much as possible, and hope that localeapp will allow translators to work by themselves. This introduces the challenge for us developers how to manage them in git - that was what I was trying to explain very shortly. Now a bit more elaborate.


When a new feature is added, there is the developer of the feature - call him Devon -, and a maintainer of the foodcoops/foodsoft repository - call her Molly.

Developer Devon:

1. Works in a feature branch in his own repository. Devon is free to use plain-text in views, or to use i18n right away - whatever he likes. [#]
   
2. When Devon considers his feature ready to be merged to foodcoops/foodsoft, he makes sure that any plain-text parts are properly i18n-ised. English texts must be included.
   
3. Devon submits a pull request. [#]
   

Maintainer Molly:

1. Molly reviews the pull request. If she, for example, finds plain-text that needs to be i18n-ised, she comments on the pull request and asks Devon to add some changes.
   
2. When the pull is ready for inclusion into foodcoops/foodsoft, she makes sure that there is no difference between localeapp and the source tree.
   
1. She checks out master from foodcoops/foodsoft
2. She does a `localeapp pull` (or perhaps `localeapp update`) to get the latest localeapp changes
3. If there is any difference (`git diff` shows anything), she reviews the changes and commits them.
4. Now localeapp and the source tree have the same idea about texts.
   
3. Molly merges the pull request into master.
4. Molly pushes changed locale files (at the very least the English one) to localeapp using `localeapp push`
5. Molly retrieves the locale files from localeapp using `localeapp pull`
6. If there is any difference (`git diff` shows anything), she checks that those are syntactic changes and commits them with commit message "fixup localeap roundtrip".

This makes sure that translation changes from localeapp are clearly distinguishable from merges.

This is just my idea of how it could work. We have no agreement on what the state of master should be (should it be fully translated? should it always be production-ready? do we have freezes? ...) so depending on that this may be adapted.
I hope this brings a little more clarity. I'm not too happy about the involvedness of the procedure, so please share if you have thoughts on improving it!

Best,
- Willem

[#] If Devon happens to have access to foodcoops/foodsoft and the feature is relevant to all foodsoft users, he might create a feature branchin the official repository. Then he doesn't need to submit a pull request, and might take Molly's role too.

[JuliusRapp]

Hi Willem,

now I (almost) got it. The point I missed about locale files is that there are independent versions for localeapp which have to be pulled/pushed (i.e. changes in localeapp are not 'live' of course).

Why does Molly need to perform step 5? If all changes from localeapp and the pull request are merged and subsequently pushed to localeapp, what is the gain of another pull from localeapp?

Julius

On 06/14/2013 12:10 AM, wvengen [via foodsoft] wrote:

Maintainer Molly:

1. Molly reviews the pull request. If she, for example, finds plain-text that needs to be i18n-ised, she comments on the pull request and asks Devon to add some changes.
   
2. When the pull is ready for inclusion into foodcoops/foodsoft, she makes sure that there is no difference between localeapp and the source tree.
   
1. She checks out master from foodcoops/foodsoft
2. She does a `localeapp pull` (or perhaps `localeapp update`) to get the latest localeapp changes
3. If there is any difference (`git diff` shows anything), she reviews the changes and commits them.
4. Now localeapp and the source tree have the same idea about texts.
   
3. Molly merges the pull request into master.
4. Molly pushes changed locale files (at the very least the English one) to localeapp using `localeapp push`
5. Molly retrieves the locale files from localeapp using `localeapp pull`
6. If there is any difference (`git diff` shows anything), she checks that those are syntactic changes and commits them with commit message "fixup localeap roundtrip".

[wvengen]

On 14-06-13 09:43, JuliusRapp [via foodsoft] wrote:

Hi Willem,

now I (almost) got it. The point I missed about locale files is that there are independent versions for localeapp which have to be pulled/pushed (i.e. changes in localeapp are not 'live' of course).

Correct.

Why does Molly need to perform step 5? If all changes from localeapp and the pull request are merged and subsequently pushed to localeapp, what is the gain of another pull from localeapp?

The committer probably has added text to the locale files manually. When localeapp imports them, it parses the yaml. Upon pulling from localeapp, the yaml might be emitted in a different order (alphabetically), and may have different quoting. To keep future diffs clean from these non-essential changes, Molly ends with step 5 and 6.

- Willem

[benni]

hey willem,

could post the instructions in the foodsoft wiki? I also have no
experience with localeapp and it would be very helpfull.

Thanks a lot.

Am 14.06.2013 10:49, schrieb wvengen [via foodsoft]:

> On 14-06-13 09:43, JuliusRapp [via foodsoft] wrote:
>> Hi Willem,
>>
>> now I (almost) got it. The point I missed about locale files is that
>> there are independent versions for localeapp which have to be
>> pulled/pushed (i.e. changes in localeapp are not 'live' of course).
> Correct.
>
>> Why does Molly need to perform step 5? If all changes from localeapp
>> and the pull request are merged and subsequently pushed to localeapp,
>> what is the gain of another pull from localeapp?
> The committer probably has added text to the locale files manually. When
> localeapp imports them, it parses the yaml. Upon pulling from localeapp,
> the yaml might be emitted in a different order (alphabetically), and may
> have different quoting. To keep future diffs clean from these
> non-essential changes, Molly ends with step 5 and 6.
>
> - Willem
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://foodsoft.51229.x6.nabble.com/Workflow-of-translations-if-adding-text-to-views-tp58p69.html
>
> To start a new topic under foodsoft-dev, email
> [hidden email]
> To unsubscribe from foodsoft-dev, click here
> <
> NAML
> <http://foodsoft.51229.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

--
pgp Schlüssel-ID: 0x3B2EE0A4
Fingerabdruck: 805F 73B1 9F45 4122 2FE6 ED75 0786 8427 3B2E E0A4

[fsmanuel]

Great guide.

Will try it with my PR if it's ready to merge.

Am 14.06.2013 um 11:03 schrieb "benni [via foodsoft]" <[hidden email]>:

hey willem,

could post the instructions in the foodsoft wiki? I also have no
experience with localeapp and it would be very helpfull.

Thanks a lot.

Am 14.06.2013 10:49, schrieb wvengen [via foodsoft]:

> On 14-06-13 09:43, JuliusRapp [via foodsoft] wrote:
>> Hi Willem,
>>
>> now I (almost) got it. The point I missed about locale files is that
>> there are independent versions for localeapp which have to be
>> pulled/pushed (i.e. changes in localeapp are not 'live' of course).
> Correct.
>
>> Why does Molly need to perform step 5? If all changes from localeapp
>> and the pull request are merged and subsequently pushed to localeapp,
>> what is the gain of another pull from localeapp?
> The committer probably has added text to the locale files manually. When
> localeapp imports them, it parses the yaml. Upon pulling from localeapp,
> the yaml might be emitted in a different order (alphabetically), and may
> have different quoting. To keep future diffs clean from these
> non-essential changes, Molly ends with step 5 and 6.
>
> - Willem
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://foodsoft.51229.x6.nabble.com/Workflow-of-translations-if-adding-text-to-views-tp58p69.html
>
> To start a new topic under foodsoft-dev, email
> [hidden email]
> To unsubscribe from foodsoft-dev, click here
> <
> NAML
> <http://foodsoft.51229.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

--

pgp Schlüssel-ID: 0x3B2EE0A4
Fingerabdruck: 805F 73B1 9F45 4122 2FE6 ED75 0786 8427 3B2E E0A4

signature.asc (271 bytes) Download Attachment

---

If you reply to this email, your message will be added to the discussion below:

http://foodsoft.51229.x6.nabble.com/Workflow-of-translations-if-adding-text-to-views-tp58p71.html

To start a new topic under foodsoft-dev, email [hidden email]
To unsubscribe from foodsoft-dev, click here.
NAML

[wvengen]

yep - https://github.com/foodcoops/foodsoft/wiki/Merging-pull-requests