Moving the translation effort to Weblate (or another open source translation system)

A better translation platform is needed.

The nb_NO translation is not good, as is the case with yet other translations.
Transifex revels in producing lackluster quality, and doing anything about it is made more difficult still.
I can’t use it at all, because the terms and conditions are draconian (which is also an issue to avoid). and
Sign in @ Hosted Weblate
are good candidates, and self-hosting is an option.
There is a shortage of people to administrate it, but I am happy to help. :slight_smile:

To be honest, I fear that changing the platform used for translations will not make the translations better. We have an active number of translators and we might lose them if we move away.

Hello, thanks for creating the request here on our forum, and thanks for chipping in and offering support! :slight_smile:

So far, Transifex seems to be working OK for us. Well, let’s say it does the job.

However, as I wrote in the original issue on GitHub, I’ve been playing with the idea of ‘moving to an open source translation system’. There are downsides to commercial systems like the one we use now, the ‘forum’ is horrible (we’d much prefer people to use our forum for general questions) and we have no way of reaching out to our translation teams efficiently.

In terms of platforms:

  • you proposed Weblate - well known player in the market used by many open source projects. And I can personally testify that it’s fine to use, as a translator.
  • I also know of translate5 (AGPL v3). Haven’t any experience with it, though (do you?) and it doesn’t really seem suitable for us (too complex).
  • Pontoon by Mozilla (BSD 3-Clause) - No experience with this one either, but from the tour it seems really convenient to use. I just translated a bunch of strings (for the Common Voice project). Actually I really like it, it feels a bit easier to me (as it’s a bit more polished interface). So I would find it cool if we could give that a try :slight_smile:

Can you tell what exactly is ‘not good’? Are there specific strings you spotted that are incorrect (apart from the fact that 138 strings are missing)? Please let me know, and I’ll try and make sure it gets improved asap. I’m afraid we won’t be moving to an open source translation system tomorrow and it’d be a shame to let mistakes linger around if we’re aware of them & could have them corrected in our next point release :slight_smile:

I would hope that we can bring a large chunk of our translators to the new platform. I actually think moving is a chance to increase interaction with our translators.

1 Like

All evidence of projects moving over to the contrary, why would that be?
Weblate holds every advantage over Transifex, not in the least among translators.

What does happen when you move is it garners goodwill and attention.
Just the ability to see what checks are failing helps greatly.
It could be that you have diligent translators that go out of their way to not make a single mistake, but
why waste their time?

Sadly Pontoon mirrors the UI of Crowdin, which is a disaster.
Mozilla only has a preference for their own projects, on their own platform.
Even Thunderbird gets a measly one star worth of importance there.
Host it yourself and you are on your own.
There is nothing wrong with that, but given how bad the translations are in their flagship product now, their platform hasn’t helped. They have other problems though.
Pontoon having a CoC and opting for a weak license is indicative of the overall direction.
Mozilla has the MPL, and while not great, why don’t they have faith in it?

translate5 seems promising. Very interesting.
It seems more like the (in lack of a better word) “professional” tools, intended more for documents.
Will keep an eye on it.

Weblate is also commercial. It however isn’t a spying closed source as-a-service only offered on awful terms. It is easy to mistake commercial for proprietary.

There are plenty of mistakes and improvements to be made in the source strings too. I only looked at ¼ of them and it isn’t as good as it should be.
Improving the stringbase of Transifex is not something I want to do.

A post was split to a new topic: How to participate in translations

What do you mean with this? What checks are you referring to?

Like I said: I like the UI and UX of Pontoon as a translator. It’s simple, clean and has clear statuses & indications (e.g. the status of a string, indicated by the coloured square in front). Sure, maybe the source of inspiration is a ‘disaster’. I don’t care about the source of inspiration. I’m looking at what Mozilla built there, and judging that only.

Can you specify what parts of the Pontoon UI/UX you don’t like or what has bothered you when using Pontoon as a translator, specifically?

Hmm, that could pose extra challenges indeed, in case something goes off. However, if we self-host Weblate, wouldn’t that be the same? We wouldn’t be able to afford a paid support subscription. Regardless of us self-hosting Weblate or Pontoon, we’ll have to rely on the community, and bugs that aren’t a priority for the parent ‘organisation’ (Mozilla or Michal Čihař) will have to be fixed by the community. Downside being of course that Pontoon’s self-hosting community is smaller than Weblate’s.

Yeah, that was my impression as well. Not really suitable for our translator audience I think.

Yes, you’re right. I should’ve said ‘proprietary’.

As source strings need to be updated in the source code, you’re most welcome to submit a PR on GitHub. I’m speaking English on a daily basis and haven’t spotted many major issues so far. Then again, I’m not a native speaker and I haven’t actively reviewed all strings. But I must say I’m rather surprised, so even if you wouldn’t be able/want to do a PR, could you give an example? are the checks for the entire Hosted Weblate instance.

Pontoon splits the translation field into half the available horizontal space. This inserts breaks arbitrarily.
That means more line-shifts between having to track different parts of a string and a translation.
Weblate has issues too, but it is the best we have.

The PR is in. App language reworked by comradekingu · Pull Request #5313 · AntennaPod/AntennaPod · GitHub
As much as the original strings explain things “well enough”, the effect is that of making any one thing “more than clear”, resulting in everything becoming diffuse.

The nb_NO translations and some of the others are in way worse shape.
A generational loss is to be expected, but a lot of it has to do with the tool used.
Similarly, I uniquely will probably have made some mistakes to that effect.
Just look at the things I caught briefly proofreading my own edit.

Sorry, was this in reply to a specific comment? Ah, I realise it’s about your earlier comment about being able to see what checks are failing. That’s certainly helpful! Weblate documentation

I had to think a bit about what you meant, but I see now. I first thought you were suggesting that line-breaks were introduced in the string (which would be some kind of bug), but I believe you’re just referring to the linebreaks in the view.

In my Weblate set-up, I have the pretty much the same field width in Weblate & Pontoon:

Also, AntennaPod doesn’t have many linebreak in strings, so this problem/challenge would occur less frequently in our case.

Apart from this, what I think is not great about Pontoon, is the inability to mark a string as a problem. It’s very easy to tag the person responsible for a string/project (easier than in Weblate), and there are ‘Fuzzy’, ‘Warnings’ and ‘Error’ statuses for strings but I don’t see how strings can be marked or flagged as such - maybe because I have limited rights).

What’s great about Weblate, is that it has this massive ‘Translate’ button on a specific langage page within a project, which is really inviting to get started. In Pontoon it’s not clear how to get started (I’d click on ‘Missing translation’ to get those strings). Also, it supports different navigation paths:

  • Project > Language > Component
  • Project > Component > Language

Pontoon only offers the former.

Lastly, in Weblate it’s possible to up- & downvote suggestions - in Pontoon it’s only possible to accept/reject them.

On the other hand, what I really like about Pontoon is the clean interface:

  • It’s clearer what I need to look at, and I’m not feeling insecure about where to click.
  • It tells me what I need to do, and gives quick access to an overview of shortcuts.
  • My ‘preferred locales’ are presented on the side, and only support me when I can’t get further with the source string (this decreases the chance on deviation from source).
  • There’s not two rows with in total 7 tabs with extra information: instead, string info is displayed right below the string, human suggestions are (always) displayed below the edit field, and further info is available on the side.

Also it’s possible to set translation deadlines for projects in Pontoon, which is very useful for preparing the next release. Do you know if this is possible also in Weblate?

You mean that whenever the source text might not be abundantly clear, translators give there own spin to the text to make better, and with it, introduce unwelcome differences between languages? Yes, I have actually seen that in the past in our project. A problem indeed.

In our current platform as well is in Weblate & Pontoon it’s possible to signal such issues with the source text directly in the affected string. I guess it’s important to monitor new translations and flag up the issue if the translation deviates from the original - in that respect we need a closer community and more ‘training’. So for me the problem is (limited) investment in people, rather than technological capabilities.

With strings spanning longer than the shorter available space, linebreaks (in the view of translators) are inserted arbitrarily.
In Weblate you can use Zen mode to have almost the full horizontal space available.
Regular mode in Weblate has one one of those side-panels.

The translation field and the actual source is further not removed by a whole lot, so there is less vertical spanning.
Try to get more strings and languages in view, and you will

Yes the red and green is stupid, and will show up as shades of brown to colour-blind people (if that).
We can discuss how Weblate isn’t perfect, or we could have moved to it and have improved matters greatly.

What I mean is that if you explain things to death with no caution for what actually needs explaining, it takes away from the few things that actually do.