We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

OpenSUSE Weblate: Easy Way to Translation

00:00

Formal Metadata

Title
OpenSUSE Weblate: Easy Way to Translation
Alternative Title
openSUSE Weblate Translation Tool
Title of Series
Number of Parts
63
Author
Contributors
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
openSUSE has a new tool for translations support: Weblate. It should become a central point of all openSUSE translations in future. In this talk you will become familiar with Weblate. Starting with translation and fixing errors in existing translations will be easy for you.
13
38
Thumbnail
23:08
44
Thumbnail
25:53
Translation (relic)Computer virusSoftware developerProgrammer (hardware)CompilerFormal languageCartesian coordinate systemComputer programmingComputer animation
DisintegrationDuality (mathematics)DivergenceOscillationSystem of linear equationsContinuous functionSynchronizationCodeTranslation (relic)CompilerProjective planeWeb 2.0Text editorBookmark (World Wide Web)MathematicsString (computer science)Computer fileTelecommunicationDivergenceSystem of linear equationsBranch (computer science)Endliche ModelltheorieResultantDifferent (Kate Ryan album)CASE <Informatik>Video gameFlow separationRepository (publishing)Programmer (hardware)Moment (mathematics)Physical systemSet (mathematics)Computer programmingReverse engineeringTraffic reportingStapeldateiSource codeWeb page2 (number)INTEGRALSoftware bugWritingDirection (geometry)Computer animationProgram flowchart
CodeSystem of linear equationsTranslation (relic)View (database)Revision controlCompilerEndliche ModelltheorieDecision theoryFormal languageConnected spaceSource codeContext awarenessBranch (computer science)Type theoryCodeSlide ruleWeb 2.0Server (computing)Network topologyMessage passingOpen sourceMathematicsResultantProjective planeSet (mathematics)Group actionSystem administratorBridging (networking)System of linear equationsDressing (medical)Lipschitz-StetigkeitRepository (publishing)Similarity (geometry)CASE <Informatik>XMLProgram flowchart
Parallel portData modelImplementationCompilerEndliche ModelltheorieGoodness of fitFormal languageProjective planeString (computer science)System administratorGame controllerMathematicsPresentation of a groupDifferent (Kate Ryan album)Branch (computer science)FreezingWeb 2.0JSON
Execution unitWeb 2.0Complete metric spaceElectronic mailing listCompilerFlow separationProjective planeInternationalization and localizationBranch (computer science)String (computer science)Computer fileFormal languagePlanningGraphical user interfaceComputer programmingFitness functionContext awarenessLoginOpen sourceLecture/Conference
Execution unitLetterpress printingPhysical lawSource codeLink (knot theory)Lecture/Conference
Hacker (term)Virtual machineString (computer science)Address spaceInternationalization and localizationCodeWeb browserSoftware testingOpen setArc (geometry)Lecture/Conference
Computer animation
Transcript: English(auto-generated)
Hello. My name is Stanislav Grabitz, and I will talk to you about translations. Translations are not complicated from the aspect of programming.
It is just correct using of Gettext and those tools. But it is complicated from the aspect of the workflow, because the programmer is not the person who translates.
And many translators are involved for many languages. So to get the translations into the application, we need a way how to communicate with translators and with developers and interchange the data.
The old system, which we are still using in SUSE, is the ILCN based on SVN. This is just an SVN repository with a lot of POT files and PO files with translations. It's command line only.
So it is easy to use by programmers, but not easy to use by translators. Translators have to use SVN, which is a programmer tool. And there is no integration with the system.
So programmers have to do many steps by hand. So it looks just now as you see. The source code is present on GitHub. And programmers have to regularly get POT files
and manually upload it to ILCN SVN. Then translators will get PO files manually again. And then translators will translate there. And programmers, again, will PO file manually upload to OSC
together with GitHub changes. So sometimes it doesn't run as described. And the path from GitHub to OSC takes seven years. Just for example, when we migrated some packages,
we found this fact. So we just need something different. There is, again, a problem with LCN. The branches started sometimes in 200, 2004,
before NLD when old SUSE translations have been moved to a novel Linux desktop and used by professional translators as a base. Then those professional work has been moved to SLE 10, again, with strings
based on the old SUSE, then again to SLE 11 and SLE 12. And only a few strings which have been new have been taken from OMP-SUSE. The result is a great divergence. Some projects have half of the strings different in OMP-SUSE and in SLD 12.
So if you test SLE 12, and if you test Tumbleweed or Leap, you will see that the translations are completely different for the same package.
This is something we don't want to have, because one single project, two translations, two terminologies, and two translators, and work done twice. So there is a new tool called WebLite.
This is something completely different. It is web-based. So anybody could start with translations. But still, custom editors are supported so translators could download it, edit it in favorite editor, and upload again.
It is integrated with Git and GitHub, so it can push directly to Git. And when we are using GitHub, it gives a notification from GitHub changes back to WebLite. So the strings in POT files will appear in seconds in WebLite.
And reversely, changes in translations will appear in not more than hours back in GitHub. Well, and WebLite has quality checks, so many batch translations could be fixed
before we get a bug report. And WebLite has an API, just new feature, so we can write batches for downloading, uploading, and manipulation with it. So how it should look in future when WebLite will
be used for most projects? WebLite will communicate in two directions with WebLite. And packagers has only to take a package from GitHub and submit to OSC. And this way could be automated,
so any change from GitHub could result in automatic submit to OSC. So in the best case, when WebLite translator will do some translation, in two hours, we will have it in GitHub. And in several hours, we will have it in repositories.
Well, and the translation model will look differently again. The Tumbleweed will be based, continually developed, and in some moment, we will branch it and create
SLE translations, LEAP translations. In case of SLE SP2, it will be only a few packages, but we plan to base our translations on Tumbleweed for SLE 13.
Well, now we have started the pilot project. This is a set of packages that are common for SLE and for LEAP and OpenSUSE. So we have to solve the problems with commercial translators and communication
between contracted translators and community. So we decided to pick several packages to test it. And there are two possibilities how the code is developed. One is with one code base, when the same code is used
for both OpenSUSE, Tumbleweed, and SLE. So the translation base is also the same, and the translators have to cooperate with community. There are two packages in this model, libzip and zipper.
And those packages will be based on WebLite translations. And the second model is the model with two branches when two branches exist in the repository, and two branches can be translated separately.
But still, WebLite is capable to copy changes from one branch to another branch. This type of package is just a slide show, which has a LEAP branch and a branch for SLE. Well, just the web for the translation server is easy.
As you can see, there is a tree where you see a project, branch, language, and you can translate. There is a source in the package. There is a translation you are entering.
There is a similar translation. You can pick languages which you are interested in. And there you can see nearby messages in the source, suggestions, in this case, SLE-Merch-Robot, which is a tool which attempts to unify
the translations between SLE and LEAP, suggests the translation that has been used in the last version of SLE. And some of the translators should decide which is the best one. You can accept and edit and delete such a suggestion.
So if you don't decide, if translators from the community don't decide this week, then the contracted translators will be paid for decision of the final translation. Then it is possible to create a glossary
for a particular language. And here is a connection to the source. So you can get source context by one click. And there is a lot of quality checks.
So many translations which are not fully correct are cached just before any commit. And translators can fix them. And the result which appears in GitHub will be correct.
So there is an example from one project that has very many of those checks. Well, and this is what you will never see in WebLite. This is a model which is used internally
by WebLite for permissions. Here, there are a set of permissions that can be dedicated to some users of groups. And administrator will decide which
permissions will be granted to particular users. So just now, the whole open source WebLite is open for editing anything by any registered users. And unregistered users can make suggestions of new changes.
It will change in the future because we plan some quality improvements. We will plan to create review teams per language. So some people which are trusted and made
in past good translations will become reviewers and any other members of community which wants to translate to the same language has to do some suggestions. And suggestions will be reviewed.
And then only trusted users will get permission to edit particular language. When it is then this planned advanced privileges support, which will help fine-tuning of privileges for particular users. So there could be administrators for a particular language that
have been privileges only to manipulate with particular languages or particular projects. Well, then something we will need for 100% review
is the support for work on different branches. Then we will need 100% review for SLE that is done by contracted translators. But community should be free to continue in translation in Tumbleweed.
So we will need some implementation improvements to support this. And this is very related with support for freezes. So we can make freeze of translations in some moment and send those translations to reviewers. So reviewers will be sure that they
are reviewing exactly with which is planned for the release. And the last feature, maybe not last, but just now last, is the pending review model. When translators will be able to translate, the string will appear immediately
in the GitHub and in the project. But it will be checked like a string that needs a review by trusted person. So we will have better control over all changes that are done. Well, this is everything for the presentation.
And now we can look into the package, into the web itself. The only method that we can use for login is just now integrated with OpenSUSE infrastructure.
So your OpenSUSE login can be used in the plate as well. Then you have a dashboard where you can subscribe to languages and projects you are interested in. But you can look at all projects. Just this is a complete list of packages
that are now translated into the plate. You see that there are some packages I have mentioned for the pilot project, but some only packages in OpenSUSE. And we already support community by several projects
like ICL or ICVM, where our L10n is upstream for translations. So we can look how it looks.
You see two branches. You can pick branch you want to translate. You can pick your language. And now you are in, and you can start to translate.
Just you can, for example, only look at the checks. Only the strings with checks.
There are nine such filing strings in German translation. For example, here you can see the problem that the translation is the same. It is probably correct. So you can here decide to delete such check and save
and go to the next string. So I think it is very easy to start the translations, even if you don't anything about PO files and POD files,
even if you don't nothing about SVN. And so you are welcome to start and participate because translation of OpenSUSE cannot be done without community because translators don't speak your language very probably.
So do we have any questions? Are there any plans to add some kind of screenshots
or possibilities to see the GUI of the program to verify, OK, is this translation fitting in this context or? Well, screenshots don't exist yet. That's such feature. And very probably it will not happen because it is not.
It's complicated, I know. It is very, very complicated. You can only look at the source code. This is a link directly to the GitHub. I'm thinking about possible feature, just apply on fly,
but it would need many hacking so the host machine will download any string from the blade like a test drive. But it is just an idea, no code is written for it.
So I didn't mention the address. This is L10N OpenSUSE.org. Anybody can browse there and start.
So thank you.