UPDATE - sep 19th: Latin wasn't the most convenient choice after all so we quickly uploaded an intermediate release 1.21 where the fallback encoding is MacOSRoman again. At least it works like it did before.

In releases 1.0 and 1.1 SRS tried to open a SRT subtitle with UTF-8 first and when that completely failed, tried it with the MacOSRoman encoding. Very often an old non UTF-8 subtitle open reasonably with it with 98% readable characters. The drawback was that e.g. Cyrillic files most of the times opened too with however something completely unreadable. In release 1.2 the encoding can be chosen so in principle their is no automatic fallback. SRS became more strict so to say. Files which opened smoothly in the past now return a blank screen an a message complaining about the wrong encoding. The "old" behavior can be more or less simulated just by choosing Latin as the encoding to open a file with or even as a preference. Remember UTF-8 slowly seems to become the standard so you might want to save your subtitles with an UTF-8 encoding from now on.

It's just a matter of choice. We could leave it strict, re-install a sort of Latin fallback or even try to guess the encoding automatically knowing that this is not a 100% safe procedure. Let us know what you want. We will take it into consideration.

That means probably that the translation machine can't handle the language pair. You'd better UNDO the action and translate again with another machine. Sometimes both machines just can't handle the asked language pair.

If you've set the switch to "Translate all subtitles", it sometimes happens that a translated subtitle is put back on the wrong line (most of the time 1 or 2 lines before the original) and another is not translated at all. This happens because the translation machines sometimes mess up the batch of the "to be translated" text. Technically, the index belonging to the subtitle line is ruined or disappeared. Of course, you won't have this problem if you translate line by line :).

?

SubtitleReSync was started with only the western European languages simply because we could (sort of) read them and test if the translation made any sense. Also the encoding is an issue because e.g. Japanese, Chinese, Hebrew, Russian and Hindi often are encoded with something else then UTF-8. Since it seems to work fair, we've added a few languages in version 1.1, with e.g. Russian as an experiment, and see how the community responds.

Secondly, because the translation is done by 3rd party translation machines, we're dependent from the possibilities of those various machines. Google and Microsoft do a good job and can handle a lot more language pairs then e.g. Yahoo's Babelfish. This also means that the quality of the translation can not be any better then what these machines can deliver.

Today (August 2011) most (larger) western European and Scandinavian languages, Romanian, Hungarian, Czech and Russian are on the list.

?

This a difficult issue for us simply because we can't read it so we don't feel comfortable testing it :(. As an experiment, we have included Russian as one of the from/to translation languages from version 1.1 onwards (to be released in August 2011). Testing the translations back and forth shows that in an UTF-8 encoding it seems to work fairly well (as good as the internet translations machines work).

We know that this is an issue for some users so we do our best to improve on this topic.

tbc