-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adhearsion should support internationalising prompts (recorded and TTS) #361
Comments
@JustinAiken made a start on this at adhearsion/voicemail#11. |
Okay, couple of points to get this discussion started...
Perhaps any keys passed in the option hash could be checked against variables to be interpolated? So you'd do something like: Not sure if I like that idea though, because then users would have to double check the list of option keys already in use to make sure they don't use a reserved word... or maybe we could have a single key with an interpolation hash? Anyways, my random thoughts... curious as to what ideas you guys have had. |
So far, using an option such as "i18n: true" has been the most flexible way to pass options to any media control method. Luca Pradovera On Sep 2, 2013, at 12:35 AM, JustinAiken notifications@github.com wrote:
|
Re "i18n: true", this feels messy and unnecessary to me. Can we just treat symbols as i18n keys if i18n is globally enabled? Or maybe if we simply detect that i18n translations are available? Examples: play :woodchucks, interpolations: {resp: 4}
play "You said #{resp} woodchucks. That's obviously wrong.", interpolations: {resp: 4} If you need namespacing (like play :"woodchucks.response", interpolations: {resp: 4} @JustinAiken makes an interesting point about being able to interchange audio files with TTS strings. Perhaps if the i18n lookup returns a URL we can treat it like a recording? PS. I'm not sold on the word "interpolations" but can't think of anything better right this second |
So, I'm perfectly happy with this sort of syntax: play t("You said %{resp}. That's obviously wrong!", resp: 4) I don't think we need to integrate translation key lookup into core As for audio vs TTS, I figure we should approach this the same as the auto-detection in If we were to do any kind of integration, I favour the latter approach with a slight twist, combining the two keys: play 'woodchucks.response', i18n: {resp: 4} So that's lookup dealt with, here are my real concerns about i18n as applied to voice applications:
Lets do one round of feedback on these points and then decide on a direction in which to start a spike of this. |
I really like this, I think we should go with that. Makes it easy to use in any method ( play "file://universal_wrong_sound.wav", t("You said %{resp}. That's obviously wrong!", resp: 4), other_play_option: :other_play_value
👍
The twist is nice, better than
I think this would go outside of i18n and depend on the language - one could pass non-English strings directly to
Perhaps a
I think exceptions/ending calls should be avoided at all costs... fallback to
Hmm, good question... perhaps we could have a rake task that generated the necassary
If we allowed specifying record location (either absolute, or relative to record "#{t("record_dir")}/#{call.language}-#{SecureRandom.uuid}", options But since all
Yes. And perhaps if we're clever, we could use i18n to allow the Simon Game to be run using either TTS or record files... two birds, one stone! I have no useful thoughts on points 4 and 7 at this time. |
👍 These two suggestions work for me.
I think you mean handling of translation where the translated string is itself an SSML doc? Yes, I agree that is a requirement.
Agreed. Asterisk does this with channel variables, so each call can be in a different language and the setting can be applied for the lifetime of the call. We also probably want to allow for an application-wide default via configuration.
Why would they not match up? Can't we use ISO language codes for everything? Perhaps I misunderstand your concern.
This is an interesting question. I think that the service provider is a backend configuration choice and not something the application (or hte application developer) should have to worry about. Thus the backend should handle selecting the appropriate renderer based on language code if that is a requirement. I believe this is how Tropo/Voxeo PRISM does it today.
If we log anything it should definitely be an error, not a warning. We could attempt to speak the translation key directly as well. Also, we could trigger the exception handler without actually throwing an exception. The rationale there is to prevent stopping the call while still hitting the exception catcher (like Airbrake) to increase visibility of the error.
I favor some kind of default convention.
I don't know, but certainly this problem has been solved somewhere before? Where can we look for inspiration?
Recording distribution? Not sure what you're asking.
Agreed. We still need Examples on the website too, but I digress :)
|
+1 for the Rails-style approach. It is clean and widely used. Would you start off supporting a YAML backend then eventually adding more? |
My point on recording distribution (which has been misunderstood above) was one we've discussed previously. If an application has recordings, should we provide a way of bundling them in the deployment, and perhaps providing an HTTP interface to serve them up to the engine? Is this even a concern we want to conflate with i18n or should we treat it entirely separately? |
Let's not conflate the HTTP interface to serve recordings with the i18n need to be able to reference them. Historically we've always bundled recordings with the application as an asset, much like you would bundle images into a web app. I think that should continue, and perhaps we need a separate issue open to discuss how best to share those recordings with the telephony engine, especially in cases where they are not on the same server. But for this issue's purposes, let's assume they are on the same box and |
Ooh, recording distribution... haha, that makes more sense than what I thought it did. |
with languages there are more issues, for example rules. Furthermore, it's not simple to do fail-over for languages when using telephony. I also would suggest to support multi-language "menu" (IVR) command, and be able to program a much simple solution for things like: For Spanish press one, for French press two etc... |
Hi guys, adding my thoughts as one of your Adhearsion users who will need this feature soon.
+1 to the Rails approach. It would be least surprising for people coming from Rails background.
+1 to this. In fact, I think this would probably a 'must have' for internationalized Ahn apps and it can be a plugin instead of a core feature to let people opt-in if they need it. |
Once a locale can be set and is used for translations, that kind of menu can be easily built in application logic. Inviato da iPhone Il giorno 06/set/2013, alle ore 08:49, Bhavin Javia notifications@github.com ha scritto:
|
Language selection IVR should definitely not be a core feature, but a plugin would be great. Would be a very small plugin, and would make it so adhearsion applications could do something like: def run
answer
if call.from =~ /some_region_check/
call.set_language :english
else
invoke LanguageIVRController, languages: ["English", "French"...]
end
end |
Pinging on this issue. It sounds like we made a lot of progress toward decisions on it. @benlangfeld this is a candidate for Adhearsion 2.6? |
It is on the cards for 2.6, yes. It's also a potential candidate for a GSoC project should we be successful this year. |
A start on this has been made in https://github.com/adhearsion/adhearsion-i18n. Feedback welcome. The plugin is an experiment, and will likely be merged into core if it works well enough. |
We're going to merge adhearsion-i18n into core, including documentation on the website, for the 2.6.0 release. |
Closing in favour of #557 |
This is the place to discuss how this will work. Pinging @bklang and @JustinAiken
The text was updated successfully, but these errors were encountered: