Translation - Use GitLocalize

[chikathreesix]

Hi, I am Ryo, a creator of Locki.
Thanks @bebraw for allowing me to open this issue.

Locki(https://locki.io) is a website localization tool that enables your localization community to easily translate your docs on your website. Check out this video to learn more about how it works.

Now Node.js is also considering using Locki(nodejs/node#8798) and here is the test integration so try this out.

Feel free to ask me any questions!
We'd be happy if we can help Webpack's localization challenges.

[lcxfs1991]

@chikathreesix hi Ryo, this is interesting.

1. I have a question for this. Is the owner has the right to approve or reject the translation?
2. Where is the translation data? Is it stored in locki's server?

[chikathreesix]

Thanks @lcxfs1991!

We don't have an approval process for everytime. But you can take 2 types of approaches for this.

a) The owner can restrict the edit only to the specified members so it will be fully under the control of the team. And we will enable users out of the team to suggest translations so that the owner and the team can approve or reject those suggestions (this is under the development now).

b) We will introduce a rollback feature soon to reject a translation that the owner doesn't want.

These are stored on our server but you can fetch the JSON anytime from API. We will enable you to easily download them too.

[sokra]

@chikathreesix Any plan to tackle the FOUC (here: Flash Of Unlocalized Content)? (You see the english version for a second)

---

@chikathreesix Have you considered using a git repo (github) as backing store for locki. Each change is commited to a repo of the users choice, permissions from repo are used. This would make intergration pretty easy and looks safer as data storage from user perspective. You could still cache the data on your server.

[lcxfs1991]

@sokra @sokra
Agree.

Guess we can create a folder/content/ lang/zh, /content/ lang/jp for contributors to translate the doc. And nominate someone responsible for reviewing the translation version.

Then after Locki resolve the above problems, we can consider migrate to that system.

[bebraw]

Organization-wise it might be interesting to push the translations to repositories of their own and consume them as a dependency to the main project. Easier to handle perhaps as you can keep language specific issues there.

[sokra]

@lcxfs1991 Maybe I wasn't clear. I like Locki, for reason that we don't have to maintain localized versions of the pages in our repo. My comments were just general ideas for locki. I think it's fine for us in the current state too. I don't care much for the FOUC in our case, but it could be an issue in a more serious application.

[lcxfs1991]

So the first step is to wait for Locki's setup then we can kick off. That would be good too.

[chikathreesix]

@sokra Thanks for your questions!

Any plan to tackle the FOUC (here: Flash Of Unlocalized Content)? (You see the english version for a second)

Yes, we are planning to implement server-side rendering in order not only to solve FOUC but also support SEO for language versions. How do you guys host your website?

Have you considered using a git repo (github) as backing store for locki.

We are storing all changes on translations as a history so that users can eventually go back and forth between the versions. We are making Locki as like a github for localization but using git itself on the background is a really interesting idea!

[bebraw]

@chikathreesix The current version is hosted on top of GitHub Pages. The site follows progressive enhancement so that you get content even when JavaScript is not enabled.

[sokra]

We are making Locki as like a github for localization but using git itself on the background is a really interesting idea!

I meant push and pull your localizations from github. An edit pushs a commit to a specified github repo. When fetching localization locki will fetch them from github (using your server as cache). Basically locki syncs with a github repo, while the repo is authoritative.

[chikathreesix]

@sokra
That's interesting. Since Locki can work as like github, we are not currently considering integrating with github itself. But if you have some use cases that can be solved with github integration, we can consider implementing something to support it, but maybe in a different way. :)

[bebraw]

FYI, there's a Chinese(?) translation here.

[chikathreesix]

@bebraw Looks cool, is this supported by your core community?

@sokra I am sorry for my late reply. What kind of file format are you expecting to be pushed as a commit with the github integration? I think it is possible to push html files to the specified repository.

[bebraw]

@chikathreesix I found it by coincidence. Looks like the Chinese community did something on their own. Cool regardless.

[chikathreesix]

Hi @sokra, @bebraw and @lcxfs1991 ,

After getting lots of feedbacks, we have changed our direction and just launched this product as the beta.
https://gitlocalize.com/

Check out the video on the homepage to see how it works. GitLocalize pulls from markdown files your repo, parses them into trackable chunks and links original copies and translations automatically. Also, it provides a split view optimized for translating long-format docs and sends a pull request back to the repo.

I believe GitLocalize would fit your needs more.
Try it out and give us any feedback!

[skipjack]

@chikathreesix the tool looks awesome based on the video, thanks for keeping us posted! It seems we currently have two translated versions of these docs in the works and only one, the chinese version, in production. @lcxfs1991 @Lutece what do you think of switching over to a setup like this? Would this make things a bit easier for you?

Maintaining the translations in this repo would be a big shift and increase the scope of this repo significantly. For example, one of the advantages of the current forks is that separate issue sets can be maintained. I'm not saying this is a no-go but definitely something to consider. Interested in what the rest of the @webpack/documentation-team thinks as well as the people who are currently working on translation.

If we do decide to go this route, I think we need to finish the knocking down most of the backlog and cleaning things up beforehand.

[Lutece]

@skipjack I used translating solution 'transifex' last year, I thought that 'Locki' is good for maintenance. I am expected to finish translating at the beginning of July. Should I use 'Locki' when I finish translating

[skipjack]

Transifex looks interesting but we need something that's free for open source I think.

Should I use 'Locki' when I finish translating?

Keep working on your repository for now. Once you've put up the site we can add a link to the korean version in our language dropdown. We'll keep this open and ping you if we decide to make the switch to the Locki. Like I said, we probably want to work through more of our backlog first and then possibly make this switch once things are a bit cleaner.

[chikathreesix]

@skipjack @Lutece Thank you so much for checking it out!

Let me clarify that Locki will be deprecated so please consider using GitLocalize. I believe GitLocalize would fit your needs more.

Transifex previously provided the tool for free for OSS but not sure now and they don't support Markdown file AFAIK.

As @skipjack pointed out, currently GitLocalize doesn't support forked repos and it expects all localized files into one repo. But to answer to your concern, what we are trying is basically having issue/pull request equivalent features on GitLocalize (we already have review request, which is similar to pull request) so that the community eventually can do all the localization related communications on GitLocalize.

Feel free to let me know how we can help :)

[skipjack]

But to answer to your concern, what we are trying is basically having issue/pull request equivalent features on GitLocalize (we already have review request, which is similar to pull request) so that the community eventually can do all the localization related communications on GitLocalize.

Ah thanks for that clarification, that would make me feel a lot more comfortable switching over. Re "Locki" / "GitLocalize" terminology -- point taken. I'll update the title of this issue.

[km-tr]

@sokra I tried to translate Japanese by GitLocalize, but because the part of webpack.js.org original notation could not be translated, it is under consideration in another way.