Workflow of translations if adding text to views

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.


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?


  • Willem

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?


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!


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

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?


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

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.

Great guide.
Will try it with my PR if it’s ready to merge.

yep -