Hi Terje,
On Mo 20 Feb 2012 19:59:09 CET Terje Andersen wrote:
Hi Moritz, Mike & all
Den 20. feb. 2012 11:12, skrev Moritz Struebe:
Hi Mike.
Most important thing is that such a translation service does not conflict with manual translation commits. No, this should of course not be the case. Basically I am thinking of an upload and a download script. The upload-script will take the latest files from GIT and upload them to the server. This _can_ be triggered using a cron job or done manually. The download script will download the files and update the git. I'm not sure yet, whether it is better to do
On 2012-02-20 10:46, Mike Gabriel wrote: this manually or by using a cron job. None the loss the workload should not be lower than accepting a patch. Using the client is described in [1]. It even denies to update the local files when updating from the server, if you made local changes. :) Or if someone else checks a new version into git you can automatically update the version on the translation server.
Cheers Morty
I've used transifex, rosetta and pootle before and I'm not a big fan, the only two positive things (in my view) with them is that they make it easy for "drive-by" translation (not dedicated translation). This might be a big plus if what you want is a greater numbers of languages (which might, or might not be completely translated), but I think the quality goes down on the actual translation. With the web-based solutions also the amount of collected words, with their potential translation, from all the different projects using the service might be of help to someone, but still might lead the translator into using wrong words because of the missing context and the fact that others have chosen this word (in another, not related project).
Thanks a lot for this statement. That is my gut feeling with such
services, as well (but I could have never expressed it that clearly).
I'd rather prefer translators being more close to the project.
Passers-by-translation, we should avoid that.
With Qt Linguest, often the dialog will be shown (Wow! I wish this would be the case for all the strings :p) which helps tremendously in understanding the context of the strings currently being translated. With po-edit it's more like the web-based ones, it's not easy to understand the context.
Yeah! Unfortunately, this has to be sad about poedit. You have to know
the application, where the string are within the GUI widgets, etc.
- Keep clean and concise (and always updated) instructions on how to do the actual translation, how to create the patch, and finally where to send the patches.
- Give translators git commit access (somehow I see this one as being the least likely to happen :p).
about 2): I can definitely see this happen for people who have sent
reliable patches a couple of times (like you and Daniel have over the
last days, also like Milan has in terms of code, recently).
In my view, translators, web-page admins and documentation writes in a project on equal footing as those who commits small code-patches - all being potential committers to either git, or wiki/web. As people show commitment, trust should be given in different levels and on different arenas.
+1 from me.
This isn't an argument for giving me git, or any other access, it's just my point on view and my points towards the web-based translation services.
I got that! Good points given.
Anyway, I guess I'll be committed either way in translating X2Go, (as long as you want me, that is :-)), it's your choice what to use ;-)
If you may, you can start through with the smaller projects
(x2godesktopsharing, plasma-widget-x2go, etc.). ;-)
Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...