Monica: Suggesting a localization platform

[yarons]

Hey, I'm a Hebrew localizer and I wanted to ask if there's any chance you might consider using Weblate as your main translation platform.

I can contact the owner of the hosted version and try to get a hosting the translations there, there's also an option to contribute the translations directly back to the GitHub project (commit for each translated string or to a specific branch so it won't create any clutter on the commit log).

There are many others such as Transifex, Crowdin, etc. (Most of them non open source) I can help with them as well if needed.

[phrohdoh]

What is the benefit of an online platform instead of editing textual files and committing those directly to source control?

[BranTurner]

@Phrohdoh I suppose it makes it more accessible to translators who aren't familiar with Git/submitting PRs.

[yarons]

Further more, in Weblate for example you can set a notification whenever new strings are added or current strings are changed and it's much more friendly and translator oriented, I personally thing that translator ≠ developer, they have different set of skills and different challenges.

EDIT: This works directly with the source control so you don't have to merge the changes back.

Thanks.

[Nebucatnetzer]

When I was working at SilmROMs we used https://crowdin.com/
You can apply for a free account if you're an open source project.
However I don't know if they accept mixed onces.

The advantage of such a tool is as mentioned by BranTurner that you remove the barrier for people to contribute.
In addition it gives you a nice overview over the status of each language and the crowd can verify a translation before it gets approved.

[yarons]

@Nebucatnetzer Sadly Crowdin is not open source and requires merging the changes back, it's a possibility though.

All the features you mentioned are also available on Weblate 😄 .

[Nebucatnetzer]

Aye absolutely true. Sorry I only half read your post too me it doesn't really matter which tool we use.

The features were more meant as an explanation for Phrohdoh.

[djaiss]

The problem with tools like this is that they are one more system to take care of. The more integrations we have, the harder it will be to maintain on the long run.

That being said, https://github.com/themsaid has created a package to manage Laravel translations string https://github.com/themsaid/laravel-langman-gui.

I can see how we could package this into Monica. Users would be able to contribute easily, request access to become translator (not everyone should be able to change the strings), etc...

[yarons]

No RTL support yet, well, there is for Arabic but not for Hebrew, Farsi, Uru, Divehi, N'Ko, Aramaic and all other RTL languages 😄

I still think that using a dedicated and heavily developed system is much better than using a plugin but it's your call.

Kind regards.

[djaiss]

@yarons Thanks for your input. Indeed, I agree with you on this part, but I think we need to make sure Monica works well before we integrate a new system, I believe. I want to support all the languages in the world after that!

[yarons]

@djaiss Hey, of course I would like to see a more stable product but I don't think that it should affect the fact that people will translate in the meanwhile, and this is exactly the strength of an external service, it has nothing to do with the roadmap and current pace of the project, you just let it handle everything for you with only configuration and zero programming or integration.

There's also an option to launch a Weblate account without integrating with GitHub for pushing the changes back, that way Weblate will pull from the repository and update all the relevant source and target strings and then some manual work will be required to push it back.

Transifex can also do that pretty easily, again, no effort is required from your side unless you want the translation to be pushed backed automatically (either to master or any other branch).

Kind regards,
Yaron.

[Nebucatnetzer]

I agree this services work very well in parallel with the project. If a language has reached a certain you can then merge it into the project.
In addition if someone complains that their language is missing you can point them to the website.

However I would totally understand it if we would wait with this until Monica becomes a more complete project.

[phrohdoh]

Having worked on a number of very large products with localization support I concur that MonicaHQ does not need to integrate (and possibly tie itself) with a separate product for this.

Changing these files is not a complicated matter and there is plenty of online material for git+github.

There is always the github web interface which you can edit and commit with.

[yarons]

It's definitely not mandatory, Weblate is an open source service allowing you to discontinue any time you like, you are free to keep commiting the translations manually if you like, using the code directly giving you no statistics, no convenience, no RTL support (The words are reversed in GitHub editor in Hebrew for example), no TM, no suggestions, no screenshots, there might be several other functions…

I'm managing several localizations for open source projects and translating several hunderds of other projects, working directly on code is bad practice and many good translators are giving up because of all the hassle.

Translators are not developers, they should focus on translating, not learning how to work with GitHub and commit and push, this has nothing to do with localization.

[phrohdoh]

I mentioned the GitHub web interface for precisely that reason.

You open a file, click the pencil edit icon, make changes, click "commit" or even "commit and start pull request".

[yarons]

That solves only one of the problems I've mentioned and in a very poor way, you didn't even mentioned all the others…

[phrohdoh]

At this stage I do not see them as issues the project needs to allocate resources (time, effort) towards.

RTL is a pain so yes that could be better.

GitHub issues _are_ suggestions and support images.

[yarons]

This is exactly the reason why you just let an external open source non intrusive and very easy to break free from to handle this for you, so you won't have to deal with any of that, if it was non open source I wouldn't say the same.

I meant contextual screenshots, not just images.

[djaiss]

I'm going to try Weblate in the coming days/weeks (as soon as I find time basically). Thanks a lot for mentioning it to us.

[yarons]

Thank you so much, I'm in direct contact with the developer if you need anything.

[waldyrious]

As a volunteer translator for many projects, I can also vouch for Weblate, Crowdin or Transifex (I've tried all three), and I could also add TranslateWiki, which is also open source (used for Wikimedia projects and several other FOSS projects).

Any of these would be great for translators, since they offer important functionality such as:

• peer reviewing
• completion statistics
• glossaries (for consistent nomenclature throughout the project)
• machine translation suggestions, suggestions from similar entries that have already been translated
• suggestions from similar languages (e.g. Portuguese > Galician > Spanish > English)
• discussions for specific items

and above all, they allow the translation to be done in small chunks rather than as a big block, which greatly encourages participation. These features make the translation process much more streamlined and more efficient, both for translators and the project :)

That said, I understand the concern of adding more stuff for the projects' maintainers to take care of. I completely understand if it's decided not to use them for the time being.

[djaiss]

And after a few months, we can now easily translate Monica with Crowdin.

https://crowdin.com/project/monicahq

[yarons]

I'm sorry but I really don't understand why do open source project select a limited closed source platform, that's totally against the spirit of the project itself.

[waldyrious]

@yarons for what my opinion's worth, the way I see it, if Crowdin are offering a service to open source projects for free, and the tool works well (which IMHO as a volunteer translator it does), then it would only be harmful for a FOSS project to refrain from using it out of principle alone.

Of course, it would be a different story if somehow the platform required a lot of maintenance, or forced the contributed data to be kept in proprietary silos, but IIUC all the relevant data is exported back to this project, so we're not really being tied to the platform. Perhaps the glossary or context data is not exportable (I don't know), but even then I suspect it may not be hard to extract it manually if we want to migrate the translation process elsewhere.

I agree it would be nicer to use (and consequently help improve) FOSS translation platforms, but given the limited energy and time of maintainers, I'm nor sure we should prioritize the interests of other projects above those of this one (assuming the choice of platform they made was based on a pragmatic evaluation of what was easier to setup and maintain).

[yarons]

@waldyrious
There are several open source projects that provide such hosting for free (Weblate, TranslateWiki, etc.) and these are pretty good products (Some would say they are even slightly superior to the closed source products), so back to the original question, why choosing closed source over an open source when both options are on the table? (As I mentioned, zero maintenance in both).

[djaiss]

I think this is unrelated.

Should I use Gitlab to host the code and not Github then? Should I use Jenkins and not Travis? Should I use my own Selenium server and not Sauce Labs? And the list goes on.

The choice of Crowdin has been made after a study of approximately 2 minutes. It was just a matter of practicality. I needed a tool, quickly, and I saw this tool that seemed to be popular and offered free plan for open source projects.

Is it against the _spirit_ of the project? Honestly I don't know. Crowdin does not own the data, we are not locked in, it detects new English strings to translate automatically which makes it super easy for us.

[yarons]

@djaiss Well, that depends, you want to be as Open Source friendly as possible without intimidating your community with monstrous systems, that's from the contributor's side, so in that case these are all great tools, if you feel that you're not compromising usability over openness it should be fine.

In terms of owning your data: no, and most projects don't but what about having the ability to use and contribute to the platform you're using? What if you found a critical bug in Crowdin and they won't handle it?

When choosing open source it's important to keep the contributors community involved and let them choose how involved they want to be, lock them with licenses and they will leave, and in terms of platforms: choosing open platform over closed ones is always better because it creates new possibilities for both the platform developers and the hosted project developers.

Both Weblate and TranslateWiki does exactly what you mentioned and much more, I'm using all these platform on a daily basis and I also contribute whenever I can and I truly support the idea that I can fix and follow the things that bother of affect me the most, it's a real game changer.

I love the open source ecosystem and I believe that the fact that different projects support and rely on one another is crucial to the development of both, that's the biggest virtue of open source.
Unless you don't believe in that and it's fine but that brings the question of what are the motives behind this project?

BTW, can you add Hebrew to Crowdin?

[djaiss]

You bring excellent points, and thanks for the conversation. I'm going to review Weblate in detail to make sure it does the one thing I want it to do well: checking new or deleted strings in the English file and adding or deleting those new strings in the other locales, while making automatic pull requests when a modification is done in the translation system.

What are the motives behind this project?

I don't think you should start questioning my motives behind this project. If I didn't believe in open source I wouldn't have put the project on Github in the first place.

[waldyrious]

Some would say they are even slightly superior to the closed source products

@yarons I'm really curious as to whether you can vouch for that yourself (with specific feature/workflow comparisons) or point to people who can. I've been contributing volunteer translations to various FOSS projects for many years now, and while I certainly agree that many of the FOSS offerings are quite competent and even innovative in some specific tasks, I can say with enough confidence that, in terms of overall workflow smoothness and convenience (for the translator, and I suspect for the maintainer as well), Crowdin is one of the best choices available.

[yarons]

@djaiss I did not intend to hurt anyone, I was just showing a possible way of thought, I didn't expect an answer and I'm sorry if it came out too strong, that wasn't my goal.

@waldyrious Would you say that Weblate is less fluent than Crowdin?
That's completely subjective BTW so I don't really think there's a way to actually compare between them in terms of statistics.