I currently ran into a translation problem that would be pretty easy to fix. Unfortunately it is a pretty high initial effort needed to actually be able to fix things. While it is inevitable to have some initial effort, I found it particularly high for KDE. This is partly because the documentation just not seem to cover that use case of a user wanting to quickly fix a thing and partly because the tools that are used currently. Regarding the documentation: I found (among other) - https://l10n.kde.org/ - https://techbase.kde.org/Localization - https://l10n.kde.org/docs/translation-howto/ - https://techbase.kde.org/Development/Tutorials/Localization/i18n - https://community.kde.org/Get_Involved/translation This seems pretty fragmented to me. Unfortunately I also did not find a good guide how to quickly(!) set things up straightforward in order to fix things. Regarding the usage of tools: I'd really appreciate if I could just fix things via a Browser via either a web based repo with a web editor (like GitLab) or probably better for not only quick fixes via specialized tools like Crowdin, transifex or their Open Source equivalents. I read that currently SVN is used which also introduces more fragmentation (since git is used for source code versioning). Hopefully this can be improved in the future. I imagine that low barrier entry into translations will result in much more contributors and contributions.
This is a common complaint that we hear a lot. I agree.
Some localization teams are already using web tools (e.g. the Simplified Chinese team uses Crowdin). Meanwhile, the Japanese team uses mailing list, but the steps are pretty simple, and SVN knowledge is not needed: 1. Download (Checkout) the .po file 2. Translate (Edit) the .po file 3. Upload the file to cloud storage 4. Inform the mailing list and the team leader will review and merge your changes
Ideally, there would be one unified solution and workflow that is so nice that all teams use it. I guess that having as less manual steps involved as possible for maintainance like manual merging will be beneficial. I am not experienced on how to manage localization, but I'd propose something like the following: - Manage translation files in a repository on GitLab (thus one could use the web editor to quickly create a merge request for changes). Maybe it can also be integrated into each project's git repository there (I am not sure whether this is a common practice and would be sensible for KDE). - Use a web based translation tool for all languages as the standard way of translating to make contributions easier (lower the barrier and offer nice UX). That could be hosted at https://l10n.kde.org/ and replace the current site there. - Ideally maintain a workflow for translators that prefer to use an offline workflow (don't know whether there are currently offline translation tools in use).
After a short search for open source web translation solutions I found relevant: - Weblate (seems best to me): https://weblate.org/. Should work with GitLab (https://docs.weblate.org/en/latest/admin/continuous.html#automatically-receiving-changes-from-gitlab, https://docs.weblate.org/en/latest/vcs.html#vcs-gitlab) - Pontoon from Mozilla, seems to be mostly focused on their workflow: https://github.com/mozilla/pontoon/ - Zanata (no updates in their code repository - https://github.com/zanata/zanata-platform for almost two years, seems to be abandoned) There are also closed source platforms that seem to offer free usage for open source projects. From my point of view that is also ok, but there might be some codex to not use closed source solutions?
You're not the first person to think about this. Please go into the kde-i18n-doc archives and find the requirements that we all agreed up for this to happen.
I'm closing this bug here because it's simply the wrong place. We've discussed this a million times, and we have an agreement of what needs to happen. So maybe you can actually help make it happen.
(In reply to Albert Astals Cid from comment #5) > You're not the first person to think about this. > > Please go into the kde-i18n-doc archives and find the requirements that we > all agreed up for this to happen. I did and found some discussion, but not an agreement of "all". Also it looked rather unstructured. Maybe I just did not find the right message or discussion thread there, can you link it? (In reply to Albert Astals Cid from comment #6) > I'm closing this bug here because it's simply the wrong place. > > We've discussed this a million times, and we have an agreement of what needs > to happen. > > So maybe you can actually help make it happen. I think having some centralized place to discuss this is good. It might be disputable whether this should happen on Bugzilla as a Meta bug, since there are also Tasks on Phabricator for this already like: https://phabricator.kde.org/T11070 I am ok if you prefer to further discuss this on Phabricator, but think that this should be left open as a Meta bug until it got fixed (or decided not to do) and refer anybody who want to discuss this or help to make it happen to the correct place (maybe the Phabricator task, I don't know). From the discussions I read on the mailing list, I saw this topic might have been touched very often but never really got discussed or decided on what to do. I might be wrong though, so feel free to link to the thread you were referring to with the requirements that all aggreed up on.
(In reply to Claudius Ellsel from comment #7) > From the discussions I read on the mailing list, I saw this topic might have > been touched very often but never really got discussed or decided on what to > do. I might be wrong though, so feel free to link to the thread you were > referring to with the requirements that all aggreed up on. It has been discussed several times, including the same task you mentione (https://phabricator.kde.org/T11070). The starting point is still here: https://marc.info/?l=kde-i18n-doc&m=143561152919896&w=2 Keeping the system opt-in is still a requirement (we do have many offline translators and even an offline translation program, Lokalize). Switching the underlying storage is not a problem: the people who works with it are fine with subversion, the people who want a graphical system don't care about what it is about. This is not to say that it can't be changed, but it is the very last step, after a lot of automation is in place. A non-free software is out of question. In other words: it's not like installing a software and everything works magically. Any system should not make the work of the people who maintain the infrastructure more complicated and should integrate with the rest. Before any such software is implemented we need a solution which minimizes such manual work (as discussed in the ticket), which means less renames. The recent flattening of the repositories structure helped, but we need still a way to identify po file renames and handle that automatically, or split files (this is where we can get help, for example). Moreover a lot of teams are using POSummit (https://techbase.kde.org/Localization/Workflows/PO_Summit) which allows teams to track all the translation branches in a single branch merging the various files, but some steps each team needs to be are still manual (summit, merge and scatter) and this is the reason why it hasn't been pushed as a general solution. If we implement a web tool on top of the systems, it would make sense to have it work with the summit branch and, which would means automating summit operations in a reliable way and migrating everyone to summit, for example. Regarding the documentation links you pointed out: documentation can be improved, but the document you pointed out mostly don't overlap and there is no fragmentation, with one exception. 1) https://l10n.kde.org/ -> translators website 2) https://techbase.kde.org/Localization -> This is/was meant to be a replacement of 3). Maybe the replacement plan should move forward 3) https://l10n.kde.org/docs/translation-howto/ -> see 2) 4) https://techbase.kde.org/Development/Tutorials/Localization/i18n This is not for translators, but for developers on how to write localization-ready code. 5) https://community.kde.org/Get_Involved/translation - this is the subsection of "translations" of the general Get Involved starting page. It is meant to be a compass, and in fact refers to 1) and 3).
(In reply to Luigi Toscano from comment #8) > (In reply to Claudius Ellsel from comment #7) > > > From the discussions I read on the mailing list, I saw this topic might have > > been touched very often but never really got discussed or decided on what to > > do. I might be wrong though, so feel free to link to the thread you were > > referring to with the requirements that all aggreed up on. > > It has been discussed several times, including the same task you mentione > (https://phabricator.kde.org/T11070). > > The starting point is still here: > > https://marc.info/?l=kde-i18n-doc&m=143561152919896&w=2 Thanks for linking. It seems it is currently still an ongoing discussion which has been revisited several times because it has not been come to a conclusion or plan to move forward with this. The most concrete progression I have observed so far was an offer from a student to look into this during GSoC last year, which unfortunately did not seem to have happened. Also I saw several requests to have a public site where progress, decisions and requirements are tracked, since there seem to have been some discussions outside the public available scope (also caused by technical reasons of bad availability of a document on this). I agree with such suggestions and propose to either use the Phabricator task or a Wiki page to keep track and document all related stuff so nobody feels left out on this. > Keeping the system opt-in is still a requirement (we do have many offline > translators and even an offline translation program, Lokalize). I read that often on the mailing list. Is this documented somewhere? > Switching the underlying storage is not a problem: the people who works with > it are fine with subversion, the people who want a graphical system don't > care about what it is about. This is not to say that it can't be changed, > but it is the very last step, after a lot of automation is in place. I care about what the version control system is about. Also it might limit possible web-based solutions since I read on the mailing list that not all support SVN (weblate seems to do so, though). It might also be beneficial to switch to git (GitLab) first before adding a web-based interface. > A non-free software is out of question. Since this is a drastic statement affecting the possibile solutions pretty much, can you link a source for that policy? > In other words: it's not like installing a software and everything works > magically. Any system should not make the work of the people who maintain > the infrastructure more complicated and should integrate with the rest. > Before any such software is implemented we need a solution which minimizes > such manual work (as discussed in the ticket), which means less renames. > The recent flattening of the repositories structure helped, but we need > still a way to identify po file renames and handle that automatically, or > split files (this is where we can get help, for example). Yup, making sure not to break things is of course important. Although maybe the whole workflow can be changed (improved) during this step which might overcome some legacy dependencies or requirements in a way everyone is happy about it. > Moreover a lot of teams are using POSummit > (https://techbase.kde.org/Localization/Workflows/PO_Summit) which allows > teams to track all the translation branches in a single branch merging the > various files, but some steps each team needs to be are still manual > (summit, merge and scatter) and this is the reason why it hasn't been pushed > as a general solution. If we implement a web tool on top of the systems, it > would make sense to have it work with the summit branch and, which would > means automating summit operations in a reliable way and migrating everyone > to summit, for example. Automating manual tasks sounds pretty reasonable. > Regarding the documentation links you pointed out: documentation can be > improved, but the document you pointed out mostly don't overlap and there is > no fragmentation, with one exception. I was mainly complaining about not finding any documentation that explains how to easily get started with contribution. I just wanted to fix a small error and did not find any documentation explaining me what steps I need to do to fix that. I ended up filing a bug report here since I did not see me fixing it myself in a reasonable amount of time.
(In reply to Claudius Ellsel from comment #9) > (In reply to Luigi Toscano from comment #8) > > (In reply to Claudius Ellsel from comment #7) > > > > > From the discussions I read on the mailing list, I saw this topic might have > > > been touched very often but never really got discussed or decided on what to > > > do. I might be wrong though, so feel free to link to the thread you were > > > referring to with the requirements that all aggreed up on. > > > > It has been discussed several times, including the same task you mentione > > (https://phabricator.kde.org/T11070). > > > > The starting point is still here: > > > > https://marc.info/?l=kde-i18n-doc&m=143561152919896&w=2 > > Thanks for linking. It seems it is currently still an ongoing discussion > which has been revisited several times because it has not been come to a > conclusion or plan to move forward with this. The most concrete progression > I have observed so far was an offer from a student to look into this during > GSoC last year, which unfortunately did not seem to have happened. Also I > saw several requests to have a public site where progress, decisions and > requirements are tracked, since there seem to have been some discussions > outside the public available scope (also caused by technical reasons of bad > availability of a document on this). I agree with such suggestions and > propose to either use the Phabricator task or a Wiki page to keep track and > document all related stuff so nobody feels left out on this. > > > Keeping the system opt-in is still a requirement (we do have many offline > > translators and even an offline translation program, Lokalize). > > I read that often on the mailing list. Is this documented somewhere? In the list archives, and this can be improved (probably in the workboard of the Localization project). But it has been mentioned in that ticket. > > Switching the underlying storage is not a problem: the people who works with > > it are fine with subversion, the people who want a graphical system don't > > care about what it is about. This is not to say that it can't be changed, > > but it is the very last step, after a lot of automation is in place. > > I care about what the version control system is about. Also it might limit > possible web-based solutions since I read on the mailing list that not all > support SVN (weblate seems to do so, though). It might also be beneficial to > switch to git (GitLab) first before adding a web-based interface. The most promising solution (weblate) seems to work with svn. I still consider this not a blocker for the first evaluation. > > > A non-free software is out of question. > > Since this is a drastic statement affecting the possibile solutions pretty > much, can you link a source for that policy? Not that I'm aware of, but no one ever considered using a non-hosted FLOSS solution for repository. No vendor lock in, I think that's the basic. > > > In other words: it's not like installing a software and everything works > > magically. Any system should not make the work of the people who maintain > > the infrastructure more complicated and should integrate with the rest. > > Before any such software is implemented we need a solution which minimizes > > such manual work (as discussed in the ticket), which means less renames. > > The recent flattening of the repositories structure helped, but we need > > still a way to identify po file renames and handle that automatically, or > > split files (this is where we can get help, for example). > > Yup, making sure not to break things is of course important. Although maybe > the whole workflow can be changed (improved) during this step which might > overcome some legacy dependencies or requirements in a way everyone is happy > about it. The workflow can be improved (the flattening itself is already a small breaking change). Nothing I personally said conflicts with this. > > > Moreover a lot of teams are using POSummit > > (https://techbase.kde.org/Localization/Workflows/PO_Summit) which allows > > teams to track all the translation branches in a single branch merging the > > various files, but some steps each team needs to be are still manual > > (summit, merge and scatter) and this is the reason why it hasn't been pushed > > as a general solution. If we implement a web tool on top of the systems, it > > would make sense to have it work with the summit branch and, which would > > means automating summit operations in a reliable way and migrating everyone > > to summit, for example. > > Automating manual tasks sounds pretty reasonable. > > > Regarding the documentation links you pointed out: documentation can be > > improved, but the document you pointed out mostly don't overlap and there is > > no fragmentation, with one exception. > > I was mainly complaining about not finding any documentation that explains > how to easily get started with contribution. I just wanted to fix a small > error and did not find any documentation explaining me what steps I need to > do to fix that. I ended up filing a bug report here since I did not see me > fixing it myself in a reasonable amount of time. For the record, I forgot to answer about this. Your original issue, if I understand it correctly, was about a fix. Right now the solution is: file a bug against the i18n product, your language as component. Regarding contributions: the place again should be the workboard of the Localization project. Some of the points I explained above are missing. Automation first, then let's move forward.
I forgot to mention this presentation from Akademy 2017 in Almeria, which summarizes the full status: https://conf.kde.org/en/akademy2017/public/events/377
(In reply to Luigi Toscano from comment #10) > (In reply to Claudius Ellsel from comment #9) > > (In reply to Luigi Toscano from comment #8) > > > (In reply to Claudius Ellsel from comment #7) > In the list archives, and this can be improved (probably in the workboard of > the Localization project). But it has been mentioned in that ticket. Alright. I was thinking about documenting every need in one place. Thus there can be consenseus reached and interested people would not have to scrape together the relevant information. I will put together some first version soon. > > > Switching the underlying storage is not a problem: the people who works with > > > it are fine with subversion, the people who want a graphical system don't > > > care about what it is about. This is not to say that it can't be changed, > > > but it is the very last step, after a lot of automation is in place. > > > > I care about what the version control system is about. Also it might limit > > possible web-based solutions since I read on the mailing list that not all > > support SVN (weblate seems to do so, though). It might also be beneficial to > > switch to git (GitLab) first before adding a web-based interface. > > The most promising solution (weblate) seems to work with svn. I still > consider this not a blocker for the first evaluation. I fully agree. I just wanted to point out that while it is mostly independent of the web-based translation interface introduction, it still might be beneficial. And it might save some work to do that together so one does not have to first adapt a web-based solution to the SVN workflow and soon have to change that to git. But I am fine any way. If it is faster and more staightforward to just do it with the SVN backend, no problem. > > > A non-free software is out of question. > > > > Since this is a drastic statement affecting the possibile solutions pretty > > much, can you link a source for that policy? > > Not that I'm aware of, but no one ever considered using a non-hosted FLOSS > solution for repository. No vendor lock in, I think that's the basic. Alright. I also understand that way of thinking and with weblate there is seems to be a nice FLOSS solution available, so that is fine. > The workflow can be improved (the flattening itself is already a small > breaking change). Nothing I personally said conflicts with this. Alright. > > I was mainly complaining about not finding any documentation that explains > > how to easily get started with contribution. I just wanted to fix a small > > error and did not find any documentation explaining me what steps I need to > > do to fix that. I ended up filing a bug report here since I did not see me > > fixing it myself in a reasonable amount of time. > > For the record, I forgot to answer about this. Your original issue, if I > understand it correctly, was about a fix. Right now the solution is: file a > bug against the i18n product, your language as component. > > Regarding contributions: the place again should be the workboard of the > Localization project. Some of the points I explained above are missing. > Automation first, then let's move forward. Alright, I will look into adding that to the current documentation. Ideally in the future that can be improved so I can easily fix those things myself. (In reply to Luigi Toscano from comment #11) > I forgot to mention this presentation from Akademy 2017 in Almeria, which > summarizes the full status: > https://conf.kde.org/en/akademy2017/public/events/377 Thanks, I had a short look. Unfortunately that topic seems to be pretty complicated, so I will most likely need a more thorough look and read the documentation in more detail. Currently I still don't fully understand the current workflow.
I created a specific task on the Localization workboard now and marked it a subtask of the currently existing task: https://phabricator.kde.org/T13311. Since there have been much discussion going on already, I went through parts of the mailing list and the currently existing task and tried to summarize everything in the new description. Ideally interested people will only have to read the description to get all important information.
Thanks for your interest in this topic, Claudius!