Localization issues

[tyrylu]

When launched, locale of the user's system is not honored. Also, using ansi version of the screenreaderapi speak call is not a good idea in light of unicode. And the last, when using speechd, attempt to set correct language.

[tyrylu]

There's a patch which addresses these issues, at least in my testing.
https://gist.github.com/raw/3668849/e426fe2617a443499b342a8022caacd31bca6e1a/localization_issues.patch

[vojtapolasek]

Hi, thank you very much for sharing your patch.
I will look into it as soon as possible. I tried to use unicode strings under Windows but it caused some problems. The strings aren't prefixed with u so I decided to leave it as it is but I will try your patch.
I have created localisation base using gettext my self.

[tyrylu]

One problem which i encountered has been using the ansi version of the function which is responsible for windows speech output. If you use the wide string version (also in the patch), those problems don't arise. You didn't encounter unicode issues in the source code because you have used the english variants.

[vojtapolasek]

Okay, I have lookied into it. Your suggestions are certainly needed, but I think they should be moved into main module instead of speech.py (except for that thing which changes windows function from ansi to unicode).
Let's pretend that someone installs the game on german machine, but german translation doesn't exist yet. I think it is better to have default english text spoken in english than in german.
I may implement some command line switch to set language manually.

[tyrylu]

Certainly. Moere cleaner than using a if statement which tests the actually used synth would be a language property which in the case of windows would do nothing. This would require separating the speech classes and a way of selection the right one (something similar to the approach in accessible_output).

[vojtapolasek]

Well, I can't see any problem, because if we are in windows, then the
identifier "speechd", won't be selected.
On 10.9.2012 11:11, Lukáš Tyrychtr wrote:

Certainly. Moere cleaner than using a if statement which tests the
actually used synth would be a language property which in the case of
windows would do nothing. This would require separating the speech
classes and a way of selection the right one (something similar to the
approach in accessible_output).

—
Reply to this email directly or view it on GitHub
#1 (comment).

[tyrylu]

Well, in this fairly simple case, you are right. I would probably not do such a big changes when they are not required, but imagine that in the future, you can come with a idea how to do this on Windows and to make things more complex, for example only for some screen readers. But i would agree that this implementation is enough for now.

[vojtapolasek]

This would be task for standalone module, I may create it sometimes in
the future. But good point anyway.

On 10.9.2012 18:00, Lukáš Tyrychtr wrote:

Well, in this fairly simple case, you are right. I would probably not
do such a big changes when they are not required, but imagine that in
the future, you can come with a idea how to do this on Windows and to
make things more complex, for example only for some screen readers.
But i would agree that this implementation is enough for now.

—
Reply to this email directly or view it on GitHub
#1 (comment).