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.
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).
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:
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. [#]
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.
Devon submits a pull request. [#]
Maintainer Molly:
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.
When the pull is ready for inclusion into foodcoops/foodsoft, she
makes sure that there is no difference between localeapp and the
source tree.
She checks out master from foodcoops/foodsoft
She does a localeapp pull (or perhaps localeapp update) to
get the latest localeapp changes
If there is any difference (git diff shows anything), she
reviews the changes and commits them.
Now localeapp and the source tree have the same idea about texts.
Molly merges the pull request into master.
Molly pushes changed locale files (at the very least the English
one) to localeapp using localeapp push
Molly retrieves the locale files from localeapp using localeapp pull
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.
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?
Correct. 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