https://bugs.kde.org/show_bug.cgi?id=423171
--- Comment #10 from Luigi Toscano <luigi.tosc...@tiscali.it> --- (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. -- You are receiving this mail because: You are watching all bug changes.
