[Kde-scm-interest] A concept for "moving to Git" and translations

Chusslove Illich caslav.ilic at gmx.net
Tue May 26 17:13:53 CEST 2009


> [: Ian Monroe :]
> I agree that there's no reason translators and programmers should use the
> same system. However I don't think letting individual projects in KDE pick
> their own VCS is a good idea. Amarok is probably going to switch before
> the rest, but this is purely transitional. Keeping all the developers in
> KDE on the same technological ship is important to the culture, and
> there's no technology more critical to development then VCS.

This depends on definition of "in KDE" :) If that means "presently in
central KDE repo", then, well, such definition is obviously going to be made
void. While (just giving examples, not a policy opinion) core modules may
all use same VCS, some extragear apps may not. For random KDE apps presently
not in KDE repo (Krusader comes to mind as prominent example), there is
neither a way (nor the need) to enforce a given VCS. But there is no reason
for a random KDE app not to be able to benefit from KDE Translation Project
(KTP), should they want so and agree to terms established by KTP.

But this is all not technically important at all, since there will be two
VCS (Git and Subversion) for some time, so VCS modularization in Scripty on
app/module side should anyway be conducted to have reasonably clean code
(even if Scripty is one big hack all the way down).

> I have no clue about what to do with docs. :) Currently they are
> completely separate from Amarok so we don't have to tackle the issue
> immediately. (One bonus of Amarok switching first is that we can phase in
> needed solutions like that one-by-one).

My strong personal opinion is that the original doc should be part of the
app, i.e. in its repository (with only open question of what one considers
"an app" in a core module, but that is a special case). I hope that would
improve the abysimal quality (doc made for the sake of requirement, rather
than for having something to say) and out-of-dateness (since the writer
wrote it only typos were fixed) that I'm encountering across the specter
while translating (haven't reached Amarok doc yet >:)

Thankfully, this is again not influencing the Scripty implementation, as
arbitrary paths can be given in the register file.

> [...] The tarball scripts could just download the translations from
> Vertimus rather then commit them to Git at all. But this is a decision for
> kde-i18n-doc, not this list. :)

Exactly, this is a matter of later concern, but do note that Scripty will
have to continue having commit access to the repo and branches given in
app's section in the register file, to push there updates to .desktop (and
possibly other) files. Vertimus-like or whatever approach is purely a
translator-side part of the equation, that would again be decoupled from how
app maintainers will fetch translations (e.g. Scripty could even commit
totally everything concerning translations into the app's repo, not only
.desktop files). I've mentioned Gnome and Vertimus only to recognize that
practically there is little novel in the outlined concept, that it has
already been used elsewhere.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090526/476cf984/attachment.sig 


More information about the Kde-scm-interest mailing list