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