Wiki translation, the future

Glad to see the Crowdin integration is going! Any question you have about me ask me, I used it quite some times (as a translator however, not as a guy who sets the project up)

Yes and its free, they checked JME out and said they would give it the open source license.

1 Like

They are going to give me an extended trial period so I can work things out with my own repo so I don’t break the JME license or tie things to the official wiki and the team.

I integrated Crowdin into a testrepo with auto build process mimicking the wiki.

  1. Things I found out are that travis-ci has a build time limit of 49 minutes.

  2. There are two ways to do this, API (issuing commands from travis using a script file) or Syncing the gh-pages folder, translating then issuing commits to the gh-pages branch that will need to be merged.

  3. There’s no way to compare the files of the wiki to the files uploaded to Crowdin so you can automate the build process using their API method.

  4. It may work by syncing the gh-pages branch with Crowdin but then you are left with issuing commits to the gh-pages branch and manually merging the commits. If for instance you deleted or added a file or folder in the wiki, you would need to know which ones and do it yourself manually on Crowdin or somehow know this by the commit on github and use that info from the commit to issue some commands through the API method.

  5. Using the API method, you would have to delete all files uploaded to Crowdin before uploading the new ones since the wiki is rebuilt every commit. This would destroy any manual translations/corrections made on Crowdin by a translator because the files are linked to each other.

  6. Crowdin is not really a translator service, they are a platform designed for translators to use to do translations. There are 3 ways to do translations.

a. Manually, i.e. monkeys doing it 100% unaided.

b. Use a pre-translator Machine Translation Engine like Microsoft Translator, Yandex.Translate, Google Translate.

c. Pay someone by using a vendor service Crowdin provides or someone you provide.

  1. The only way to really do this is with a pre-translator service and then make corrections, using Sync. Problem is the free use of the Machine Translation Engines have limits based on characters. The best free use was Yandex.Translate with 10,000,000 characters a month, 1 million a day.

The wiki has 324,000 translatable strings, ie words. This means there are no real viable pre-translation options for open-source since just one translation of one commit for one language would blow away the limit.

  1. The max amount of translations that can be downloaded via API/travis is 14 due to time limit. This take almost 49 minutes to do. If you do not automate, use sync, and push everything as a commit to the gh-pages branch as a commit/merge then it would work. Someone would have to do all this, it aint gonna be me.

In conclusion, if there were a dedicated team of wiki editors of about 50 with half being translators, this may work,

Short of that, the original conclusion of previous posts on this translation topic still hold true, its best to allow the user to translate using their preferred method. For those who feel they wish to go beyond this, they can now use the method I used in the tutorial to accomplish this. It works amazingly well and allowed me to test all this out without breaking the wiki.

P.S. This was a great learning experience for me. I learned a lot about Travis-ci and actually discovered a bug that they fixed.

1 Like