https://bugs.kde.org/show_bug.cgi?id=423171

--- Comment #9 from Claudius Ellsel <claudius.ell...@live.de> ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to