Dne Út 9. dubna 2013 08:29:56, Karl Eichwalder napsal(a):
Tomáš Chvátal <tchvatal@suse.cz> writes:
Let me tell you a "shorty" bit about my hackweek project.
I'm not that sure whether this all is actually wanted or even needed. And, more important, it looks confusing to me. But if the openSUSE community wants to go that way, it is fine with me. I'd guess the openSUSE community than would administer and manage this process (e.g., updating the translation packages, in case that that is still needed), and I could retire from it (which is also perfectly ok for me).
Check with the opensuse project management and especially with coolo whether everthing is fine.
Some general remarks.
1/ The current infrastructure sure has some weak areas. Thus, improvements are a good idea.
2/ In the context of translations, I'd avoid git as much as possible and stick with svn.
It luckily does not matter that much because both can be accessed +- the same. With the weblate you can even reduce the requirement to have svn/git installed because user can just fetch the .po whenever he feels like working and then upload it back and it will be merged automatically. No git merges/svn merges forced to be done by user.
3/ I consider branches per release (openSUSE 12.1, openSUSE 12.2, etc.) as a good thing. Sometimes teams decide to translate a term differently from now on; but this does not mean you actually want to change past releases accordingly; users are used to that translation (even if "wrong") and translated documents or third party documentation might make use of that "wrongly" translated term.
In the future (openSUSE 13.1(?)/SLE 12(?)) we already agreed to get rid of the separate SLE* and opensuse* branches.
Actually the problem is that we have opensuse/sle branches even for software that is released/branched independently and then put to the sle/opensuse. Thats why I want to put some of the things into the git to be next to the devel code (as already webyast is). The rest will be still branch by release so we match the reality. Btw this separate branches agreement would you mind to elaborate which translations will be used then? The pro ones or the community provided ones? I also hope to take look on the tools Stanislav posted to show diff for upstream application, because our task should be to provide this stuff up to them and if they decide to not use it reflect the requests by them into our translations because we are just having more people work on one translation and it is bit wastefull :-)
4/ Re-arranging and renaming packages is always a PITA. Only do it if it is really needed (and you have nothing better to do ;) ).
That I agree. It is PITA but I think it is long term worth the task as we finally know what strings are release dependant and whatnot. Also it seems that only package you do this way is the yast thingu rest is already done with the src package together.
5/ Permanent merging and updating translation files during development is bad; this only makes sense at the end of a release cycle. Of course, this is my very personal opinion; if the community thinks different, go for it.
Permanent merging is bad, but reviewed merging is pretty cool thing that allows you to fix bugs even on "stable translations". I know about software that had translations broken for 3 years stating it will be fixed with next major bump where it is already fixed. Because translators were to work only with trunk. And also other way around. Everyone works on stable branch and forgets to merge stuff. This tool will be just to easily visualise the possibilites to merge while you are translating. And it will be up to you as translator to decide if you want it to happen or not.
6/ I'd avoid the Web for the actual translation process as much as possible; it will probably result in more but even worse translations ;) (see topic 5). I'd rather go for a translation app (Android).
Yeah lots of people hate web, but I think the apps are even more crazy. I tried to translate on android and my arms hurt pretty much, the touchscreen thingy is not great for typing too much :-)
Also I bet we already have some projects that should be translated and are not. If you happen to be aware of such project we can also add it to the toolkit, just reply to this mail with its name and git repo.
It is often more important rather difficult to identify obsolete stuff...
Agreed that removing obsolete stuff is also important, but from looking on our stats we have everything in pretty much translated state so more stuff wont hurt kittens. Tom