Commit access for TranslateWiki in LibreMesh repos

[patogit]

(Continuing the conversation from PR #254)

@nicopace and @Nikerabbit (and anyone else who's interested), let's see if we can agree on how to arrange commit access for translation files from TranslateWiki. I imagine that whatever we work out here can apply to the LiMeApp too ( @gmarcos87 ), and maybe other repos if they're ready to translate before January.

How about if commits go to a protected branch for the first two months, and then we revisit the idea of TranslateWiki having direct push commit access?

In other repos, @TranslateWiki makes about one commit per month (usually on a Monday or Thursday). So after two commits maybe there will be more confidence to allow direct push... or maybe the LibreMesh development flow really depends on translations going through protected branches just like all the other code.

@Nikerabbit, would that work for you? Do you have other ideas?

[nicopace]

Noone in the LibreMesh community has direct commit access (or shouldn't have) to protect and collectivize the knowledge, and to ensure that what gets merged works by doing integration tests.

The Pull Requests are reviewed within a week tops, so doesn't seem to be conflicting with the times of translatewiki.

[ilario]

For me no problem to give direct commit access to a TranslateWiki member. Our mechanism of no one has direct commit access is for avoiding people to push bad code or useless branches, but this is not going to happen for contributions from TranslateWiki, just translations will come from them.

[Nikerabbit]

How about if commits go to a protected branch for the first two months, and then we revisit the idea of TranslateWiki having direct push commit access?

I am not sure what do you mean. We currently do not have support for pull requests and I'm not fond of doing pull requests manually.

In other repos, @translatewiki makes about one commit per month (usually on a Monday or Thursday).

I try to push translations every Monday and Thursday. Commits in each repository does not happen every time if there are no changes to translations.

Translation updates are generally very safe, except for mobile apps where the app doesn't build if translations have errors with variables or mark-up.

[patogit]

@Nikerabbit, what would be required to add support for pull requests? Where is the code that automates the process you use now to commit to GitHub repositories?

LiMeApp is a mobile app.

The software in lime-packages, LuCI, is the web interface for router firmware. Do you (or anyone else on this thread) know how OpenWRT / LEDE derivatives handle errors with variables or markup in translation files?

[Nikerabbit]

I have not researched what kind of API GitHub provides to create pull requests automatically. The code we have is not very complicated: https://github.com/wikimedia/translatewiki/blob/master/repong/repong.php

I have no experience on how router software is localised.

[ilario]

@altergui @G10h4ck @p4u @aparcar @nicoechaniz opinions? Can we do an exception for TranslateWiki?

[aparcar]

I just looked at teh PR API and it looks straight forward. @Nikerabbit could you create a fork, push updates there and auto create pull requests with the API? I'm not used to PHP and don't know how difficult it is.

[nicopace]

@ilario not possible to do exceptions, cause this is a repo lock. Better to do what @aparcar is saying

[Nikerabbit]

@aparcar It seems reasonable and there are even multiple PHP libraries to choose from: https://developer.github.com/v3/libraries/

However, integrating this into our workflow is going to take some effort and looking at my TODO list and thinking the priority of this, I don't think I will be able to do this until next year.

[nicopace]

We are very on to the pull requests... I don't believe that this will be an issue. If you send it once per week, we will aprove the pull requests same day. Can we try it without implementing and doing any changes? I am sure this is not going to be an issue... but for sure we will find out the first week of using it.

[nicopace]

Something that I don't know if I was clear enough.. All our repos are (or will be) using protected master and develop branches. This means that noone (not even the core developers) can or will be able to push changes directly to these branches without having someone else review the changes and accept them (and running the integration tests required for each branch). That allows us to:

1. distribute the knowledge and experience of those that know more to those that know less, and also reduce the risk of someone including bugs by adding an integration test step and a peer review step
2. order changes by features and fixes, opening spaces of discussion over each change

I hope this makes it clear why we respect this mode of using git so we can explore this possiblilty further.

And thanks @Nikerabbit for commiting to this process! :)

[patogit]

@Nikerabbit , happy new year! I'm returning to the translation of the LibreRouter project after a break. Any chance of moving forward with pull requests for TranslateWiki?

[Nikerabbit]

I have been busy with other things so far.

[patogit]

@Nikerabbit and @nicopace , do you think this will move forward in the next week? I can put time into making it work this week, but if it's not going to work, I will move on to a different platform, since we want to get a first round of translation done by the end of February.

[Nikerabbit]

This week? Full support for pull requests is not possible is not to do in just a couple of days even if I stopped doing everything else.

Committing to a different branch is possible.

[patogit]

Ok, then let's see if we can set up committing to a different branch in order to get translation going.

I'm happy to help with pull request support, though I'm a novice coder and don't yet understand what the next steps are.

[patogit]

@nicopace , @p4u , @Nikerabbit , maybe we can make a tw-translations branch in each repo. I'll see if I can do it.

[patogit]

@Nikerabbit , it's not currently possible to use TranslateWiki for MarkDown files, is it? If so, we could do ReadMe files, such as https://github.com/libremesh/lime-sdk/blob/master/README.md .

[Nikerabbit]

Translate extension supports translating wiki pages (any kind of pain text is okay), so you could copy the markdown readme on the wiki and make it translatable using that feature. Practically, that would mean that future changes should be done to the translatable page and exported back to the repository (or doing changes twice, but overwriting the wiki version with a fresh copy from the repository won't work).

We have one project using that approach: https://translatewiki.net/wiki/Translating:Lib.reviews/FAQ One significant issue here is though that exports from translatable pages to the repository are not automated yet.

[patogit]

EDIT: never mind, see next comment.

[@ilario created a tw-translations branch. I'm not sure how to tell whether @translatewiki has commit access to the branch. @Nikerabbit, does it look ready? ]

[patogit]

Other devs say it's difficult to configure commit access on the libremesh repos, so they suggest that Translate Wiki commit to a fork (either at patogit or translatewiki) and from there do the pull request. I think this is the most effective way to move forward until Translate Wiki can do pull requests. @Nikerabbit are you ok with this?

[Nikerabbit]

Who is going to do the pull requests?

[Nikerabbit]

I did receive an invite email for @translatewiki, but looks like someone cancelled it because the link is not working.

[patogit]

I created an organization on GitHub to handle this, https://github.com/translation-bridge . I invited @translatewiki, @Nikerabbit, @ilario and @gmarcos87 , and can invite more people. I forked the three libremesh repositories that are internationalized and ready to translate. Lime-app is the most complete at this point, with message documentation and screenshots for most of the messages.

I can do pull requests and I am happy to take responsibility to do them. Since the repos are in their own organization, we can give other people permission to do pull requests too. I live in a place that sometimes loses internet connection for a day or more at a time, so I think it's a good idea for other people to have permission in case they want to get things done quickly.

@Nikerabbit, if you accept the invitations, then both your accounts will be organization owners, so I imagine everything is ready to configure the space on translatewiki if this is ok with you.

[patogit]

I think that with this setup we don't need to create a new branch for the translations in the forked repos, but maybe I'm wrong. I think that we just need to know what branch to submit the pull requests to for each repo. In lime-app for example, @gmarcos87 was using uhttpd as the development branch. I'm waiting to hear from him whether this is still true. In lime-packages they're using develop as the branch for the next release. I'm not sure what branch is being used in chef.

[Nikerabbit]

Can you double check the branches so we get the correct versions in right away? Can you also list the i18n directories because it's not obvious to me where there might be for all the repos.

I also notices that message documentation is still empty. While you should have some, you should not empty placeholders: empty but present keys in our system would hide the fact that they are missing.

[patogit]

Here are the correct branches and translation file locations.

edit: corrected branch names to follow contributing guidelines of each repo.

https://github.com/translation-bridge/lime-packages/tree/feature/tw-translations/packages/lime-webui/po

https://github.com/translation-bridge/lime-app/tree/issue-119/i18n/translations

https://github.com/translation-bridge/chef/tree/master/i10n

[patogit]

Message documentation is empty because @gmarcos87 hasn't merged my commit yet (says it will get done today).

https://github.com/libremesh/lime-app/pull/118

[Nikerabbit]

I have an almost ready patch to add LibreMesh to translatewiki.net

https://github.com/translation-bridge/lime-packages/tree/feature/tw-translations/packages/lime-webui/po

Is there a en.po or pot file? Same note about empty qqq strings as for lime-app. I could not add this one yet.

https://github.com/translation-bridge/chef/tree/master/i10n

There is no i10n, it's either i18n or l10n :) It would be good to have some message documentation in qqq in near future.

Do you have a logo (SVG if possible) and a short sentence or two description of the project to show to translators?

[patogit]

I have an almost ready patch to add LibreMesh to translatewiki.net

Hooray!!!!

Is there a en.po or pot file [for lime-packages]? Same note about empty qqq strings as for lime-app. I could not add this one yet.

Lime-packages... I don't see an en.po file. I just made one, https://github.com/libremesh/lime-packages/pull/336 . I will try to get the qqq file done this week.

Lime-app qqq is now up to date, in the develop branch: https://github.com/libremesh/lime-app/blob/develop/i18n/translations/qqq.json -- so, as long as the screenshot links work, then lime-app is ready to go? @gmarcos87 told me that there will be new messages to translate appearing in the next few days, so when that happens, we'll update qqq and add more screenshots.

There is no i10n, it's either i18n or l10n :) It would be good to have some message documentation in qqq in near future.

Changed to i18n https://github.com/libremesh/chef/pull/42 . qqq was created with just a screenshot link in each message, and the PR says it was merged, but I don't see it... https://github.com/libremesh/chef/pull/38 ... even if that version with screenshots shows up, yes, more detailed message documentation will come.

Do you have a logo (SVG if possible)

Yes, whichever image meets your needs https://github.com/libremesh/lime-web/tree/master/logo .

and a short sentence or two description of the project to show to translators?

LibreMesh.org is an international community developing tools for wireless community networks. The firmware (the main tool) allow simple deployment of auto-configurable, yet versatile, multi-radio mesh networks.

[patogit]

@Nikerabbit , Is this sort of empty qqq file appropriate? Of course, we'd rather have documentation messages in it, but is it the correct format for an empty qqq file? https://github.com/libremesh/lime-packages/pull/337

[Nikerabbit]

I don't know if that file will parse (probably not). I would recommend to postpone adding empty qqq files until you have something to put in there. qqq can also be written inside translatewiki.net, if you find that easier.

Also to confirm, should I use the develop branch for lime-app?

[patogit]

Translate extension supports translating wiki pages (any kind of pain text is okay), so you could copy the markdown readme on the wiki and make it translatable using that feature. Practically, that would mean that future changes should be done to the translatable page and exported back to the repository (or doing changes twice, but overwriting the wiki version with a fresh copy from the repository won't work).

We have one project using that approach: https://translatewiki.net/wiki/Translating:Lib.reviews/FAQ One significant issue here is though that exports from translatable pages to the repository are not automated yet.

Ok, I'm looking at the Lib.reviews space on TWN.

(I notice that the FAQ is out of sync: https://translatewiki.net/wiki/Translating:Lib.reviews/FAQ#How_do_I_create_a_version_of_lib.reviews_in_my_language? and https://lib.reviews/faq#language the last sentence is different.)

If someday the export of those pages could be automated, that'd be great! I wonder what it would require.

We just started using Zanata to translate the LibreMesh website, partly because I didn't realize that this wiki-page-translation option is available on TWN. Due to the way Zanata functions and the naming convention of the files for libremesh.org, we can't export directly to GitHub from Zanata either. So.... maybe it will work to use the TWN wiki-page-translation for the website content, README files, and even the instructional booklets that we're creating. This way translators would only need to make an account on TWN, instead of making one account there and another on Zanata.

[patogit]

Also to confirm, should I use the develop branch for lime-app?

Use the issue-119 branch for lime-app, https://github.com/translation-bridge/lime-app/tree/issue-119/i18n/translations

[patogit]

I don't know if that file will parse (probably not). I would recommend to postpone adding empty qqq files until you have something to put in there. qqq can also be written inside translatewiki.net, if you find that easier.

So, if I'm not going to put anything in lime-packages qqq today, then we should delete the pull request https://github.com/libremesh/lime-packages/pull/337 and instead let TWN create the qqq?

[Nikerabbit]

So, if I'm not going to put anything in lime-packages qqq today, then we should delete the pull request #337 and instead let TWN create the qqq?

Yeah, there is really no reason to have qqq file until you have content in it :)

[patogit]

@Nikerabbit , is there a way in the TranslateWiki interface to change the source language for a document or for a translator? For example, a wiki page or a .po file is written in Spanish and someone wants to translate it directly to Portuguese. Another person translates it from Spanish to English, and then a third person wants to translate it from English to Turkish. Is it possible for each translator to choose the source language they know best?

Also, is it possible to show two source languages at once? I saw software that does this, maybe Weblate.

[Nikerabbit]

Translators can set assistant languages in their preferences. You still need to have all texts present in the real source language.

[patogit]

@Nikerabbit, what else do you need from us to move forward?

[Nikerabbit]

Hi and sorry about the real life interfering :). I need the pot file of course, but I'll check if I can add the other groups already and report back.

[Nikerabbit]

It seems that the changes I have requested are not present in the bridge repositories yet:

• lime-app still has a qqq file with TODO entries.
• chef still has the folder called i10n
• libremesh webui is still lacking a pot file

I see some of those pull requests are still open, some not. Is there a syncing problem to the bridge?

[patogit]

@Nikerabbit, I don't know, I'm still learning to use GitHub. Maybe @gmarcos87 @ilario or @aparcar can help. @ilario is an owner of the bridge repo.

[patogit]

Moving forward with these tasks:

It seems that the changes I have requested are not present in the bridge repositories yet:

• lime-app still has a qqq file with TODO entries.

waiting for review and merge https://github.com/libremesh/lime-app/pull/128

• chef still has the folder called i10n

fixed, see note about syncing below.

• libremesh webui is still lacking a pot file

waiting for review and merge https://github.com/libremesh/lime-packages/pull/336

I see some of those pull requests are still open, some not. Is there a syncing problem to the bridge?

I don't know how syncing is supposed to work. I just updated the translation-bridge repo by doing the following on my computer:

• cd GitHub-translation-bridge/chef
• git checkout master
• git pull upstream master
• git push origin

Is there another way to do this? A way to automate this on GitHub?

[patogit]

• lime-app still has a qqq file with TODO entries.

fixed: https://github.com/translation-bridge/lime-app/blob/master/i18n/translations/qqq.json

[patogit]

now that #336 is merged, what's the next step?

[patogit]

Do we need to make any more changes on our end, @Nikerabbit ?

[Nikerabbit]

I think the pot file is good now, but I will have to confirm by testing, but I only have time for that next week.

[patogit]

@Nikerabbit any progress?

[patogit]

@Nikerabbit, can we expect this to be working in the next week? I'm looking at setting up some other system for translating until TranslateWiki is functional, and I'm deciding how much energy to invest in creating the alternative. If TranslateWiki will be usable next week, then we'll just use a few spreadsheets. If TranslateWiki won't be available for this project until next month or later, then we'll set up a full translation platform.

[Nikerabbit]

Hi, I will check again now.