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). 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. I too have some concerns on how to do the practical merge of the manual translation patches sent over mail with the download from the web-based service. Which "wins" when there are strings which are translated both manually and on the web-based service? In relation to the work of committing the translation patches, I think that with the first patches from new translators there will be questions, something went wrong and uncertainness on how things are done. I see two ways of making the time to commit the patches sent from translators less time-consuming. 1) 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. 2) Give translators git commit access (somehow I see this one as being the least likely to happen :p). 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. 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. 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 ;-) Best regards, Terje