On Sun, 11 Apr 2010 01:02:45 +0200 Dominic Hopf dmaphy@googlemail.com wrote:
Am Samstag, den 10.04.2010, 19:11 +0200 schrieb Frank Lanitz:
Hi,
On Sat, 10 Apr 2010 13:20:02 +0200 "Jože Klepec" joze.klepec@siol.net wrote:
things look great. To do them, we need just a little push.
*Push* ;)
I plan to do Slovenian as I wrote help in next month as I have some other things to do.
OK. Great. So we have a project with translating manual to Slovenian, Spanish and as I cannot say 'no' at this moment, also to German langauage withint the next weeks / month.
But I'm not sure at the moment how to do this at best. Currently I can think of using a wiki or a git repo to work on the translations on the first hand, but also keep the basis version ( = the English one) up to date as I suggest to start working with 0.19 devel version of it. What do you think about?
At present the manual is the text file geany.txt if I see this right?
AT least the basis of all, yes.
Why not just create files geany-es.txt, geany-de.txt and so on? Writing in reST shouldn't be a problem for the translators, is it? When using the current geany.txt as basis, you would just have to change the text and save it as geany-cc.txt (where cc is your countrycode).
Yes, I think this would be a goal of the project.
Maybe the current geany.txt could be renamed to geany-en.txt so that the geany.txt will be the index-file you were talking about.
I disagree. I'd prefer something similar to LANG=C also for translations to make clear, which is the "main" translation, the fallback one.
Translators could just begin to write their geany-cc.txt and send it to Frank or this list, and when something changes on the files, send a patch accordingly. This is how translations for Geany works at present and I don't think it's necessary to change it much, unless Frank feels too stressed with applying patches. :)
Basically, you are right. Unfortunately without any support tools or support process I'm afraid translators might losing some changes inside English translation to port which might can cause conflicts inside documentation.
Cheers, Frank