Possibly use GitLocalize to simplify translation work

[chrisvfritz]

As discussed here, translation might be made substantially simpler with the GitLocalize service that @sotayamashita has generously made available to us! 😍 This looks like a great workflow, but I have a few questions/concerns for vuejs.org specifically:

• I notice only .md files are supported. Since we also have other files with localized content (e.g. .ejs), do you think it would soon be possible to support those as well? I'm not sure if it's a deal breaker - it just means some translation work would have to be done outside the service.
• Since we update these docs very frequently and translate to many languages, we currently maintain a separate repository for each language. GitLocalize only seems to support subfolders within the same directory, but I worry that this would create a barrage of pull requests that most people would have to ignore. Are there any plans for multi-repo support?

@kazupon @ChangJoo-Park @gbezyuk @ErickPetru @Jinjiang @ludo237 @Haeresis What are your thoughts?

[MachinisteWeb]

This approch is interesting because the basic translation workflow can still be used because at end point, that reverse « PR » to original, and PR from outside are always possible. So this tool is usable in a « progessive » and « incrementaly adoptable » way and it's great!

I just test it, and the tool currently not solve problems we have not already solved only with Github so in our case, that sound like a more « restrictive » process.

• We currently use the number of line to know exactly what can do translated.
• We currently let the translator use the tool of is choice for translate (orthographique help, changes in multiple files, search, .md base for translation (not the actual HTML transformation), etc.).
• We currently use the original repository as « upstream » reference to track what part of file has changed.

For example with vue-ssr-docs, we check « upstream » (https://github.com/vuejs/vue-ssr-docs:master) and merge it into (https://github.com/vuejs-fr/vue-ssr-docs:working). Because we translated french « into » en directory, all new content is noticed by new line, and all modification is noticed by « conflict » (because we have french content). Github tools are now great to solve that. When work is approved, the en directory from https://github.com/vuejs-fr/vue-ssr-docs:working is reversed into https://github.com/vuejs-fr/vue-ssr-docs:master fr directory.

It more easier with official documentation because we translate directly the good files and we have no « reversed » step to do.

I hope this tool can help team with not already simple translation process and not « restrict » current stable translation process used by others team.

I will notice that to Vuejs-FR tean to have others thoughts :)

UPDATE: Next step to allows us to adopt the tool

• Usage of .md in editable area and not HTML.
• Possible full copy/past outside tool to allows prefered tool to be used.
• Possible edition of others format, even if that is just a usage of plain textarea (for plaintext) or an uploader (for binary).

Great Job @sotayamashita !

[ErickPetru]

I believe all the thoughts exposed by the French translation team are also shared by the Brazilian team. The worklflow of using the original repository as « upstream » reference is also really important for us.

[chrisvfritz]

Just as an assurance, I'm definitely not thinking of pushing translators to use something that won't improve their workflow. 🙂 This is great information so far and I'm glad the newer GitHub tools are making translations easier!

[kazupon]

I notice only .md files are supported. Since we also have other files with localized content (e.g. .ejs), do you think it would soon be possible to support those as well? I'm not sure if it's a deal breaker - it just means some translation work would have to be done outside the service.

In about the above, We use i18n feature of hexo can be exports localized contents to a locale resource files. https://hexo.io/docs/internationalization.html

we might good to try it once. 😉

[ludo237]

I'm ok with this since I cannot follow the updates of the site very often due to my current job, it's keeping me a bit busy 😢 it would be faster for me to just translate the strings instead.

[ErickPetru]

I'm ok with this since I cannot follow the updates of the site very often due to my current job, it's keeping me a bit busy 😢 it would be faster for me to just translate the strings instead.

It's a good point. A good colaborative tool which allow us to just translate strings would be more productive than trancking and merging changes in many files. I've already collaborated with projects inside Crowdin and Transifex. Just for information, Pagekit translation is there.

[sotayamashita]

@chrisvfritz

I am sorry not to reply fast.

I notice only .md files are supported. Since we also have other files with localized content (e.g. .ejs), do you think it would soon be possible to support those as well?

We will not support .ejs but we think we can extract localized content into config file such as.en.yaml. What do you think?

Since we update these docs very frequently and translate to many languages, we currently maintain a separate repository for each language. GitLocalize only seems to support subfolders within the same directory, but I worry that this would create a barrage of pull requests that most people would have to ignore. Are there any plans for multi-repo support?

We are considering and understand your concern. If we merge other locales into one repository, PR will be getting increasing. However, I think it will not be the problem if there is translation flow. For example, what about to create locale team like Node.js. There are localization teams such as nodejs-ja or node-ko and they will review before merging PRs.

[ChangJoo-Park]

@chrisvfritz Gitlocalize is best option for translate .md. I translated SSR docs with it. 👍 But, Gitlocalize is not working well <code><style></code> syntax 😟 (