Opencast
The Future of our Crowdin Use #7326
Replies: 3 comments 4 replies
-
|
Has anyone heard of the Tolgee tool? https://tolgee.io/. At the very least, it is open source. They have in-context edit support https://tolgee.io/features/in-context. |
Beta Was this translation helpful? Give feedback.
-
|
Some questions that come to mind:
|
Beta Was this translation helpful? Give feedback.
-
|
To measure translation percentage we'd need to write code to compare keys with values which don't equal the en_US. This would be annoying, but doable imo. Multiple people editing would be handled the way things are right now, but better. Right now if translator A translates a key, then translator B changed that translation we have neither notice, nor any kind of audit trail. If we make people file pull requests we at least have a general idea of who is touching what, and when. |
Beta Was this translation helpful? Give feedback.
-
We will have overlapping values. Languages share words.
I meant translating at the same time. Not sure if we abandoned the translation week for good, but I remember it having an effect and actually bringing endangered languages over the edge. Doing this through PRs doesn't seem to be a good workflow. |
Beta Was this translation helpful? Give feedback.
-
I'm not computing per-word translations, and neither does Crowdin. If the translated value differs at all compared to the source, then it's considered translated. There's a hypothetical QA step after that to make sure the translation is sane, but we aren't doing that either for lots of languages.
Agreed, and the requirement to file PRs definitely isn't ideal. Not sure what else to do, aside from spend the time fixing up Crowdin or switch to some other tolols with unknown downsides instead. |
Beta Was this translation helpful? Give feedback.
-
That's not what I meant. We actually have complete identical values between languages (excuse my comm -1 -2 \
(curl -sSL https://raw.githubusercontent.com/opencast/opencast-admin-interface/refs/heads/develop/src/i18n/org/opencastproject/adminui/languages/lang-en_US.json \
| jq -r 'paths(scalars) as $p | [ ($p | join(".")), getpath($p) ] | join(" = ")' \
| sort \
| psub) \
(curl -sSL https://raw.githubusercontent.com/opencast/opencast-admin-interface/refs/heads/develop/src/i18n/org/opencastproject/adminui/languages/lang-de_DE.json \
| jq -r 'paths(scalars) as $p | [ ($p | join(".")), getpath($p) ] | join(" = ")' \
| sort \
| psub)This results in: Details |
Beta Was this translation helpful? Give feedback.
-
|
As I mentioned in the meeting yesterday: Studio and Tobira don't use Crowdin. This was never intended to be a "final" decision in those projects, it just never happened. For Studio, we have quite a few translations that were submitted via different means. A few people actually created PRs (e.g. Danish, Italian, French). In other cases, I had email communication with translators (either they wrote first, or I asked people). I usually then sent them the English JSON file and gave them simple instructions for non technical people. The JSON file I got back was sometimes slightly broken, but easy to fix for me. There is also this Studio issue about the topic with someone suggesting Weblate. For Tobira, we always fill out English and German during development. Only last year did we add new languages (Italian and French), with the ETH paying student translators to do it. For that purpose, @owi92 built a super cool in-Tobira UI: https://translation-helper.tobira.opencast.org/. It allows the translator to edit translations in-context: missing translations are clearly shown with a warning emoji and once you open the big table to fill out that translation, you can see it in action. It stores in-progress translations in local storage and allows users to download the translation as YAML (which is what we use in Tobira instead of JSON). There are also shortcuts (1, 2, 3, 4) to immediately switch languages. (Note: don't just use the link I sent there to start translating stuff! The keys are outdated and we have to manually rebase that patch. So talk to us first if you actually want to translate anything). It seemed like both translators liked it and they were done with all of it quite quickly. All of the above is just me stating facts, and is not necessarily an opinion on how we should do things. The Tobira translation helper, while really cool, is not perfect, both from a translator-UX perspective as well as from a technical feasibility perspective. It's probably not a good idea to manually build something like that for all Opencast projects. And to keep it up to date. It only worked well for Tobira because we had two paid translators that we directly communicated with. And both of these approaches (Studio & Tobira) are not great for continued updates of the translations or multiple people working on a translation at the same time. I think having some kind of easy UI for translation is still good. I think we shouldn't just limit contributions to people who know how to create a PR. And while including other people manually kind of works, it is annoying for a project with continuously updating translation-keys. So while I don't mind to already disable crowdin (and everything else you suggested), someone should probably try out some alternatives (two already mentioned in this thread). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
As you probably know, we use Crowdin to make translating Opencast UIs easier. We use it primarily because the original new admin ui (now the old new admin ui, which has been removed) used it, and it has worked well for our user/translator users. Knowledge of how to administrate Crowdin has always been somewhat limited within the project, and we have now reached a point where I have to question whether the time required to fix the current issues is worth it.
Our current issues issues:
developbranch still has all of the Theodul keys in it, for example, because despite removing the source file from git, that removal does not remove it from Crowdin's source keys.So, my proposal here is the following:
r/18.x), in the correct repo and then get merged forward, preserving the translate-once-apply-everywhere model from Crowdin.Beta Was this translation helpful? Give feedback.
All reactions