Serbian Translation - In Progress

[Wishmaster]

Watcher,I disagree with you. Keeping empty lines has the advantage that someone who wants to join translation can just start with translating the missing lines, he doesn't have to use refresh.bat at all.

Also it is easier for me to see which lines are missing and which are translated in the first place.


I don't care how you release them but in the SVN there should be the empty lines (its not that much for German anyways).

[watcher]

One more thing - vultures, uses our Russian lang for references and i think our way of work will fit him better, but it's for him to decide.

[watcher]

Watcher,I disagree with you. Keeping empty lines has the advantage that someone who wants to join translation can just start with translating the missing lines, he doesn't have to use refresh.bat at all.

Also it is easier for me to see which lines are missing and which are translated in the first place.

It's easier for you - for me it's useless junk that bothers me in my langpack. Once again - this is not how it was intended, you want to work like this, fine, don't say to me that it's the right way, i will not accept that for myself.

[Wishmaster]

watcher, that's fine. You use your way, I use mine.

[watcher]

Wishmaster, agreed 

[Robyer]

watcher, I see. To provide my points:

1) My way is MUCH easier for translator/maintainer to write and update translation.

• file references are useful way to understand what's being translated and where in code we can found this string. Your way completely removes them even from Untranslated folder which makes generating them completely useless in first place.
• keeping untranslated strings (and empty lines) in same file makes it MUCH easier to use with SVN/Git revision compare, because these strings doesn't jump between files but are still on same line in same file. You can easily spot the useful changes in log ( = changes done in original english translation) and when there are changed only english typos, you can "revert" the translated line (which was correctly translated without typo) with one single click.
• translating inside Untranslated and then copying the content back into translated file is useless and time wasting. Working on same file is better and faster.
• when some user wants to help with translation of single plugin, I can give him link to svn to this partially translated file (with empty lines), then he can fill it and/or fix existing translations and then send it back to me. I can simply replace file on SVN with his file and easily see what he changed, what he translated (blank lines are filled). I don't need to copy his strings manually and refresh langpack and he doesn't need to work on more files.
• when translating, it often contains similar strings like these which are already translated and I can easily see or Find existing translations to compare or inspire me. Also you can see in context of what other translations this untranslated thing is, which is helpful too.

2) These files on SVN aren't and shouldn't be the "clean result". It is the "raw" stuff which gets "compiled" into release clean form and only this is clean result that is being published.

3) You don't need to use translate.js for "compiling" release format, because yeah, it's slow (due to parsing, translating, and doing again). I don't know where/what Mataes' tool is, but it could and should easily provide stripping comments and empty lines from result file and do it very quickly. It doesn't need the already cleaned files (unless it just simple append whole files together).

I recommend to trying to solve issues at correct place. If your problem is that tool you use to generate langpack keeps comments and blank translations, then we should fix that tool. Not the way raw langpack files are saved.

[watcher]

Robyer, this is your opinion, i stay with mine, this is how we kept things for years and years before any scripts and our lang was the only one that wasn't abandoned. Let the serbian guy decide how he wants to work. Maybe your way works better for him too - i'm not saying that mine is perfect, this is just how we prefer to do things. Maybe this is harder for rest of the guys, well, than switching to Refresh.bat takes 1 minute 

[watcher]

Robyer,  even better way - http://trac.miranda-ng.org/changeset/12447

I provide 2 batch files - one leaves empty lines and references, second do not, so vultures can try both ways, choose the most comfortable one, or even use both  First - generate files with empty lines, translate whatever you want, then use the second batch file to leave it all clean while keeping freshly translated lines 

[Robyer]

watcher, yeah, ok, whatever floats his goat 

[watcher]

My goat was brutally murdered

[vultures]

Apart for not sharing the fuss over the dilemma for wrapping empty lines with ready langpacks, I certainly do share your enthusiasm. Let's be clear, using one giant langpack file, which by my own means of doing translation via langpack_russian is my own preference. I've done translations before and even with similar large outputs - and you've gotta agree how being fluent in two languages gets you places whilst directly translating into your native language is only supposed to do so. 

Knowing slavic and anglo-saxon langs is just like being able to compare bit-logic and hex-code on-the-fly, and that's an advantage I'm willing to use. On the other hand, it has nothing to do with those means that maintainers of Miranda NG utilize, like Git, SVN and Trac. As far as my opinion is concerned, the only thing I know is that GitHub is chosen descendent of SVN for online collaboration - and simply because it allows for greater developer control of large-scale projects. Imagine 30+ forks and only one (dedicated) lead dev - and on SVN - and you'll get my idea.

Since you've let me decide what the translation process should look like, lemme sum up once again:

• Acquisition of latest =CORE= export, checking references to Miranda core and commiting (check)
• Using the strings from the (most basic) langpack to build a file used for translating all the essential plugins (pending)
• Checking the version control for updates whilst attempting to translate all 20k+ lines in a master file (yet to come)
• Maintaining the translation via SVN (if I get sufficient privileges) whilst checking project status on Git.

Thank you guys. The scripts are useful tools but (and be certain of it) they are meant for guys like yourselves, already used to doing things their way, getting comfortable with whatever tools you've used all along.

For future translators sake (I don't think anyone's gonna team up with me on this immediately) those couple'o refreshing (and installing) scripts are useful for working in ready enviroments. If you had one translator for the core, another for protocols and the third one chasing the translations for remaining plug-ins this could prove very handy for somewhat internal version control and that is, before commiting to either SVN or GitHub.

With core Miranda done, I can use expressions and strings to speed up the rest of my (currently pending) translation. Its benefits are great, and I'm yet to decide upon a dedicated tool for the process.


P.S. (I almost forgot) -- @Watcher: yes, that's what SVN is supposed to offer should someone decide to team up with me.

[watcher]

Anyway - now new (and unfinished  ) serbian langpack is included here and on miranda-ng site in Downloads in Langpacks section below.

[vultures]

Aaand - thanks, really appreciate it.
I'm a dawg.