Hi Moritz, Mike & all
Den 20. feb. 2012 11:12, skrev Moritz Struebe:
> Hi Mike.
>
> On 2012-02-20 10:46, Mike Gabriel wrote:
>> 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
> 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