Shoutbox

quote:

---

Originally posted by ZrednaZ
No, I'm not checking every day for a new build. When the e-mail about release 677 came out, I downloaded the changelog and beta file at once, then translated it and handed it in on Wednesday (the deadline). However, just after turning in my 677 translation, another Danish translator informed me that he had just downloaded the change log and found that 681 was now the newest version. Of course I was annoyed about this when I had just handed in my 677, which was apparently already obsolete.

---

It wasn't "obsolete" it was 99% of the work already done for 681... Wasn't it?

I know there have been (still are?) some issues with the servers consistency for a couple of days and we're working on it, although it's not directly a translation-changelog issue.

PS: Apatik, I don't realy want to kill the dead horse again, but after checking things out in detail (almost key by key) there were indeed a massive load of inconsistancies with the change logs.

In fact, some errors might lead to wrong translations if translators use those logs as a guideline to what to change....

see [SOFTWARE - 862] [TRANSLATION] Various issues with the English translation

this is not pointed towards you personally or to someone else in specific though, but just saying that there were a lot of things to be serisouly confused about.

Hopefully, when the heat is a bit of, the next version will fix all those things...

Meh, that's alright.

For what I could read though, your other thread doesn't list that much inconsistencies in the changelog itself, only a load of inconsistencies in the language file itself...?

Anyway, it's proving quite difficult to maintain an up-to-date, accurate changelog for a language file that's almost constantly evolving, and this raises again the very first concern expressed in this thread : we should've had stopped any lang change way before actually starting the translation. Obviously.

quote:

---

Originally posted by Apatik
it's proving quite difficult to maintain an up-to-date, accurate changelog for a language file that's almost constantly evolving,

---

Actually that's not true. It's very easy to compare both files and give the translators the differences between them. As I said somewhere else, it took me only 5 minutes to code a little Perl script that shows the changed, added and removed sections and keys.

However, I agree with the following you said. Yuna should take that in mind for next releases:

quote:

---

Originally posted by Apatik
we should've had stopped any lang change way before actually starting the translation. Obviously.

---

quote:

---

Originally posted by Choli

quote:

---

Originally posted by Apatik
it's proving quite difficult to maintain an up-to-date, accurate changelog for a language file that's almost constantly evolving,

---

Actually that's not true. It's very easy to compare both files and give the translators the differences between them. As I said somewhere else, it took me only 5 minutes to code a little Perl script that shows the changed, added and removed sections and keys.

---

Maybe Apatik meant it more as in keeping track of what strings/keys are used in the software itself and which ones not (anymore), instead of what string/keys are present in the language file.

Though, for stuff like that I guess one could write a tool too which scans the source for the actual used variables/resources and store that list. Then it would indeed be a piece of cake to simply compare that list with the one from a previous build and create a language change log from that comparison to give to the translators....

quote:

---

Originally posted by CookieRevised
keeping track of what strings/keys are used in the software itself and which ones not (anymore)

---

ok, that's another thing. However, I suppose (and hope!) that developers at Yuna be careful with those things, and if they remove a control, they also remove its associated string in the file. In addition, I suppose (and hope too!) that they are using a revision control system - therefore, keeping track of the strings/keys should be quite easy. Everything is reduced to being organized and follow some methodology at work