Wahou, lot’s of ideas 
@lauriewayne1 I get your point and proposal on Airtable, and @Rachel I also agree with your comment, and I see also that it give twice more job to non English speakers when doing UG update, and can be difficult for people who don’t feel confident in English.
But I still think there are more advantages in having a single trustful version of the UG, and this one being EN, for the following arguments:
- when I’m updating French UG, either because code change, release with new things in it, etc, I’ll usually update various pages at the same time. As one change can affect multiple pages, etc. When I do that, I find it more complicated to have Airtable open and list one by one every paragrapher à I change, sometimes maybe only few words here, few words, there, etc. Than opening a second browser with English version and doing it in both at the same time.
- about the screenshots, they also need to be “translated” (taken in the language version)
- having an international shared common version will force us to phrase and think the way we document in this international perspective, which seems necessary if we have language UG (and not country ones). For instance, if we add a new payment method, in a global thinking of it we would have in this master version a table with the various payment methods available and which one can be used in which country where the OFN is deployed. Whereas we might not “think” that way if we just update in our own version, it’s just so easy to forget that the French guide is used in Canada, Belgium, and who knows, maybe some French expat in Australia…
- when a news instance join, they want to create a user guide from an existing one. It’s probably easier, until Esperanto becomes used, to consider English as the pragmatic pivot language and we want them to have access to the trustful and up-to-date version they can then translate in their new language
- especially, for small corrections it is more painful to document in airtable than just do the change …
- if I translate in french and then when you do in English you ask a sanity check (which I understand) it also take me complementary time on it anyway, and when I have my head in it when I’m in the translation, it probably doesn’t take me so much more time
- Having many notifications in many directions will make changes hard to follow
This being said, I like your idea though of having, maybe in the current Airtable in a UG dedicated section, a sandbox of “improvement suggestions” where we can from the interactions we have with user, if no time to update the UG, record that we think we should add something on that, that anyone could take and do.
So my proposal would be a bit in the direction of @lin_d_hop and @maikel with some bits of what you propose @lauriewayne1 and some notification aspect mentioned by various people:
- People write userguide additions/updates in their chosen language and then they use a web-tranlsate tool to create the English and leave it in draft mode. They then ask in the #user-guide Slack channel for some native English person to check and merge the English.
- If the update is done by en EN folk in the English master version, they leave it in draft for a short period and notify in #user-guide Slack channel @channel so every translator knows they have to translate in their own language. leave as draft enable to see all the changes… if has merged, changes in English won’t be tracked and will be impossible to update the other versions
[those two points work for small updates with new releases, customer support, etc. but also for new features] - if when we do customer support we realize something is missing in UG, we open a task in Airtable for someone to pickup later (sandbox user guide)
- Our release process should include making the relevant updates in user guides (new feature, or change that affects user guide). IMO they should be done before we release so we can link UG so users can see how new features work, etc. In that case if done first in En, we should have some “release draft” that are left 1-2 days in draft so other language translators can see the changes in English version.
That still feels a bit complex, but it doesn’t seem there is a simple process possible here…
I don’t think Trello is adapted, as how would we move the cards, for instance “I changed that sentence in my UG”… who moves it ? when everyone has checked they did change ? …
I wouldn’t object if other think we want to try first the Airtable tracking you suggest @lauriewayne1 and if people want to try this solution first.
Side thought : I think that if we don’t manage to implement an efficient process on having a single common UG, it questions for me the fact of having language UG instead of instance UG… as I see the mess it will be for support person in an instance if they have to deal with different support documentation depending on who contact them locally and which language they speak. We are in the middle of this “find the balance between efficiency through mutualization / cooperation, and resilience through decentralization and local action”… interesting process, I guess we’ll learn a lot and we could write an article to share our experience with other community at the end of the process 