Hey guys, I’m Yaron, a Hebrew coordinator and translator.
I have few things in mind for a very long time (I’ve been volunteering for over 10 years now).
First: I think there should be an indication of what is an Ubuntu original project and what project should be handled upstream, this way we’ll be able to avoid duplicate work.
Second: I’m not sure Rosetta is good for us as translators anymore, the overhead is just too much to handle and there are much better open source solutions out there.
Third: I need a way to add new contributors as suggesters only, I don’t want them to affect my translation, is there any way to do it without giving permissions?
Canonical provided the greatest tools for the contributors several years ago but nowadays these tools are somewhat obsolete and the newer techniques available in the open source ecosystem is far different and advanced than the current Ubuntu contributors tools (somewhat usable yet time consuming).
Thanks a lot for bringing this topic for discussion. I am an spanish translator, and I’ve also been affected by what you describe. Lately, I’ve been doing more upstream translations on transifex and weblate instead of launchpad.
Do you have any ideas we can start trying? Maybe we can use this site to coordinate the work and experiment.
I will invite my spanish teammates to join this discussion.
Well instead of thinking of Rosetta as the baseline we should detect our baseline elsewhere and add the missing pieces to it, for example: Most TMS (Translation Management Software) doesn’t have Bzr support, so adding a Bazaar support to a good TMS will be more beneficial than trying to improve Rosetta.
Using this as our platform is great! I think there’s also an Ubuntu Translators Telegram group, I’m not really sure about that…
Same approach, we should think about a system that supports all these from usability perspective and try and work with it to add Bzr support, improving Rosetta will be much more difficult in this case.
I agree that such information would be a valuable improvement. Not sure how it could be best done, but indeed worth considering.
Besides that I’d like to add:
As regards Rosetta:
Rosetta is part the infrastructure provided by Canonical, and something we simply have to relate to for now.
As regards some of @Rodhos’ items:
Much of what you mention is about organizing the translation work within the translators team of respective language. Please bring it up with other members of the Spanish translators team. (I see that you are the latest member there.)
Launchpad is awesome because it gives us a unified view of all the things to translate, and we get a consistent experience. But I now feel that the future of translations is upstream. That will mean that we have to adjust to the tool preferred by upstream, and we will need to organize in some other way as a community that translates many projects.
What do you people say if we start a tour using the different translation systems out there? This way we can discuss about what we like and dislike, and how we imagine it being integrated into a distribution wide project.
So after leaving my thoughts about the whole translating process (that will be also usefull to discuss inside the team) I would like to imagine some tools that could be really helpful for us.
A glossary with labels would be great since we can not only supply comments but classify words. I mean some kind of system with metadata.
Secondly a system that allow us to better manage keyboard shortcuts detecting matches and separating in sections if possible.
I know but Rosetta is for our usage, we should have an open communication channel with Canonical and tell them why we think the current situation is problematic and how we can work out on alternatives for the sake of both of the sides.
Who do you think we should contact? There’s no actual representation of localization leaders in this forum?
I’m not sure how active it is. I will add an action on the Community Council backlog to contact them. I would like to join.
But, what we need to solve the problems in rosetta is technical work. And the launchpad team is just on maintainance mode, so I don’t see it happening. Let’s invite the launchpad team in here too, to see what are their thoughts and plans.
What we previously talked about in this thread is that Rosetta is not intuitive enough, using Transifex, Weblate, Crowdin, Pootle and TranslateWiki altogether made me realize that Rosetta is obsolete and there are many outstanding issues.
TM is managed poorly, if I want to add or consult the TM it’s not part of my flow, I need to visit a different page in order for it to appear.
Placeholders have many false positives, if the original strings have % percent, then % p is considered a place holder and I can’t save the actual translation.
TM suggestion should also show similar terms as a list.
Indication for original or upstream projects.
The list is too long to address all of this right here, Weblate has a Bazaar integration through plugins, maybe we should try and see if we can adjust it to our needs rather than fixing an obsolete system which has almost no maintainers nowadays.
LP’s translation software is not just the translation interface, but also the hub for dealing with Ubuntu’s language packs. Replacing it would be a really big project.
If you want to sell such an idea, it’s people at Canonical you need to convince, and to have a chance to make them even listen, I suppose that you’d need to make up a really long list of shortcomings which can’t be easily fixed and which are important enough to give the investment in setting up new software priority.
Some things to keep in mind:
Most translations are done upstream anyway; even more so now when Unity is (almost) not maintained. Translations via LP need to be done for
the relatively few projects for which LP is upstream wrt translations, and
Ubuntu specific strings added to upstream packages via patches.
For LP translations you can either use the web interface or download and edit the PO files with any tool you find convenient.
Finally:
What’s TM?
The placeholder issue you mention is probably not too difficult to fix. Maybe a gettext issue similar to LP: #1756547.
I agree, yet if Canonical believes in community and localization it should be considered.
It’s been so long that this tool is neglected that it should be relatively easy to accomplish, I can just add the feature list from all the translation tools I’ve mentioned.
As convenient as it may sound, it’s not so convenient (I’ve tried it for several times), I think that the general approach of neglecting the source project is not a good practice and although it would require more resources this is also the translators’ effort and in the trade off of sacrificing my time over Canonical’s resources it’s pretty unfair that the contributor will donate more time to keep everything intact while the main benefit from the upstream project is for the sake of Canonical and not the translator.
Translation memory, it replaces the translator’s memory and good TM makes good translation because instead of checking for references manually the translator can just have a quick look over what was previously used and maybe even search the entire translation (and potentially several dictionaries and auto translators such as Bing and Google Translate).
I can try and assemble the list of demands for a good translation system based on these but what are my chances here?
Ah, thanks. The LP interface does provide suggestions when an untranslated string is translated in other packages.
My personal belief is that the chance is small that big changes will happen soon. I think it would be of greater benefit to the community if you and other experienced translators helped with improvements within the scope of the present software.
That’s the most basic and almost irrelevant form of TM, you should see how other systems do their TM integration, I should be able to control it, having some suggestion based on certain percentage of match is not good enough.
I’ve been trying for years but since I can’t add anyone without giving them inferior permissions than mine they are changing my strings and translating with different manner and I can’t keep track of them so I just give up in the first place and I won’t let anyone in.
The current TM is a joke. If a dot is changed the suggestion is gone.
Yesterday I corrected some bad stings automatically imported from upstream. I was surprised because the string I modified was already translated 4 years ago so when I input the right text it was translated by another person and reviewed by me.
I realized two things: All translations once made are hiddenly stored and imports from upstream overwrite our previously made translations.
I’m talking about huge mistakes like translating “IPv4” into “IPv6”, leaving half text in english, using “:” in a interpreted list separated by “;”, using words that doesn’t make any sense in spanish like “mapping” - “mapear” a made up verb, and so on. I just can not overlook this. Would you?
Good news is I can finally access to one of those upstream profiles and look in his “last worked on” translations to check them since before it was a blank page with the message “X does not use launchpad. This page was created on x-x-x when importing the X translation…”. Other profiles are still the same.
Oh, great! Thanks for getting so involved in this topic!
I see many problems, but I’m not interested in fixing them in Rosseta, it’s clear that launchpad is in maintenance mode, and translations are not going to change that. I see a bigger issue on how we work, and what I want to propose is for our ubuntu teams to join the upstreams, get involved a lot earlier in the process. Then, as you mentioned, we can use rosseta only to translate the few strings that are ubuntu-specific.
What bothers me is that that’s how it has been supposed to work for a long time. Translations should always be done upstream as far as possible. This is true also when strings from upstream projects are made available in Rosetta, which is typically the case for packages in “main” whose translations are provided to the Ubuntu users via the language packs.
Rosetta is thought to be used mainly for
projects for which LP is upstream, and
Ubuntu specific strings added via patches.
Besides that Rosetta can be used as a supplement. For instance there may be a time lag before upstream translations make it to Ubuntu, so to compensate for that certain strings can be translated via LP soon before an Ubuntu release.
But the fact that you find it motivated to say what you said in the quoted text above suggests a need to inform the translators teams about the workflow for translations. The ubuntu-translators mailing list is still the hub to discuss translating of Ubuntu, and at least one member from each translators team should be subscribed to that list. (Probably that is not always the case…)
I will work upstream from now on. Thanks for explaining how is supposed to be. I’m new here.
We are all subscribed to the mailing list and we also have a Telegram group but the truth is we don’t use to talk very often and I barely get a response.
