Internationalising

[DFranzen]

I would like to add a German translation for this skill and am able to translate into German and test of the German Echo myself. In my fork I have added this in a naive way without any 3rd party framework. Let's have a discussion

First of all I would unify the way the responses are created. You have the smart_response, which takes care of the mp3 url, if it is needed, but some places still call speech_response directly. That means even though Alexa is invoked with the squeezebox skill, her grip on the "Pause" and "Resume" Intents might run out. Additionally I think it is weird that the two routines audio_response and speech_response have different signatures. I propose using the speech_fragment sub-routine for both of them and make the order and number of their parameters equal.

The unification would make it easier and cleaner to implement the internationalisation how ever it will be implemented

Concerning the framework I have the feeling, that a 3rd party framework would make the handling more rigid while not providing any additional functionality for the usecase of this Skill, because it is only generating static responses anyway. But I am happy to let you guys convince me of the opposite.

[declension]

Thanks for the detailed issue.

First of all I would unify the way the responses are created. You have the smart_response, which takes care of the mp3 url, if it is needed, but some places still call speech_response directly.

Yes it's a little haphazard I agree. I think I originally just converted a few key responses to keep the session alive, without burning more bandwidth or adding more latency to the response than necessary, but perhaps these are both negligible and I like the idea of cleanliness...

Additionally I think it is weird that the two routines audio_response and speech_response have different signatures. I propose using the speech_fragment sub-routine for both of them and make the order and number of their parameters equal.

This sounds like a great idea :+1:

Concerning the framework I have the feeling, that a 3rd party framework would make the handling more rigid while not providing any additional functionality for the usecase of this Skill

I hear the complexity argument, and am also keen on avoiding 3rd party libraries, hence suggesting sticking to the standard library here, in particular Getttext.

because it is only generating static responses anyway. But I am happy to let you guys convince me of the opposite.

Ah - but not so static. In your version in fact there were lots of template variables (which is great), and potentially some number forms - which brings up the tricky issue of plurals. German and English are identical in their handling of these but other languages have quite complex rules (e.g. Polish, Russian, Arabic - even French is slightly different) - see the Gettext pluralisation docs and examples.

Gettext (or similar tooling) also allows

• contributors to use standard tooling for translation (we use it for 30+ languages in Quod Libet)
• produce errors on missing translations (if we want), or default back to a locale, typically en_US (which is generally what we want)
• It also supports the regional differences whether pt_BR vs pt_PT etc. In fact squeeze-alexa is really currently in en_GB, which has small but significant differences from en_US (both generally and in Alexa itself) - but with the defaulting this becomes easy and DRY.

I'm not wedded to this alone... but want to make sure there's a path to covering some / all of these types of things for other languages as well as British English and (German?) German...

[DFranzen]

Alright I understand your point about gettext now. I will have a look, whether I can convert my fork into gettext easily.

Maybe in the meantime we can already do something about unifying the functions generating the responses. What do you think about the function definition I have got? def *_response(speech=None, title=None, text=None, reprompt_text=None, end=True, store=None): Any objections against these parameters in that order?

The speech_fragment then uses text as speech, if speech is not given and vice versa. I thought that is a good idea, since usually the speech output and the text output should be interchangeable. In my experience most skills just display the speech response in the card. And if you want the speech to be a bit less formal you can explicitly provide both.

Yes my German is de_DE. I don't think Alexa supports any different German Languages yet.

[declension]

What do you think about the function definition I have got? def *_response(speech=None, title=None, text=None, reprompt_text=None, end=True, store=None): Any objections against these parameters in that order?

This seems reasonable I guess :+1:

Alright I understand your point about gettext now. I will have a look, whether I can convert my fork into gettext easily.

I will help with this, it's a bit involved / oldschool getting some of the tooling (inttool etc) set up but once it works and the strings have been wrapped in _("foo bar baz") it's pretty easy to work with.

[declension]

@DFranzen this is merged now, so in theory translation is possible. It's not perfect but should handle everything in theory.

I've added some translation docs...

[DFranzen]

Well done. I saw you were working on this yesterday evening. I will add my translation in the next few days.