I18n for numbers (voicemail counts, dates, etc)

[bklang]

It appears that the Voicemail I18n file lacks the entries necessary for reading back numeric items.

• Verify that the I18n version of Voicemail has all necessary translation hooks for numeric readback
• Add missing entries to en.yml

[bklang]

@polysics Would you take a look at this?

[lpradovera]

The specs on everything involving translation are essentially non-existent, since everything is mocked to never even hit I18n and the returned output is not correct.
adhearsion-i18n returns SSML if the translated key has a text property, not the plain translated string.
In my opinion this needs an overhaul of the tests first, followed by splitting the interpolated strings so they are no longer interpolated. After that, we would need to borrow some methods from ahnsay to turn, for example, "120" into "one hundred twenty" and not "one two zero".
All said, I think I need more context, such as what the end goal is and what brought the issue to surface.

[benlangfeld]

@bklang We can't seem to figure out exactly what the observed problem was here. This ticket jumps too quickly to a solution to know if that's the correct solution or not. It seems what you're doing is sending language-specific string replacements of digit strings to TTS ("one two zero" instead of "120") rather than letting the engine handle this. This seems wrong to me, and is what <interpret-as/> is for.

[bklang]

The initial story was because of a simpler problem: when reading back message counts, the numbers weren't included in i18n properly (they were interpolated, which is not supported by adhearsion-i18n) and therefore not present in the provided en.yml. Since those numbers are counts, there's no need for <interpret-as/>.

While it's unlikely that any mailbox will have more than a handful of messages, we should probably provide translation strings at least up to a hundred (which is/was Asterisk's hard-coded limit for app_voicemail).

I'm not sure I understand where "120" or "one two zero" comes into play? What function needs that kind of readback?

[benlangfeld]

The point is that you havn't provided a reason to impose a limit like 100. Why are we using 'one' when we can use '1' and therefore not translate at all, or impose any kind of limit?

[bklang]

The reason to impose a limit is that we have to define a limit somewhere. Numbers go on to infinity, but we can't provide infinite numbers. There's a practical limit to voicemail messages - it would be hell to sit through listening 100 messages one-by-one, let alone 1,000 or 1,000,000. I'm not suggesting we impose such a limit, just that we don't need to go out our way to support it without someone presenting a good reason.

Regarding "1" vs. "one": The en.yml serves two purposes: the obvious one is translation, but the less obvious one is documentation. I use the en.yml as a comprehensive list of audio prompts that must be recorded by voice talent. When Adhearsion Voicemail gets included into an app, we need to add the list of prompts required here to the list to be recorded by the voice talent. Because we can't assume TTS is always available, we need entries in en.yml so that audio prompts can be created. This will likely also mean adding a dependency on numbers_and_words and deprecating/removing ahnsay.

[benlangfeld]

I notice that this gem does not implement the adhearsion-i18n gem's advice about interpolation and goes ahead an interpolates message counts as well as dates.

Is this what you're referring to, Ben? I still don't feel like I understand your intentions behind this issue.

[bklang]

I notice that this gem does not implement the adhearsion-i18n gem's advice about interpolation and goes ahead an interpolates message counts as well as dates.

Yes this is what I am referring to.

[bklang]

Also, that to have i18n provide translation for numbers, we'll need to add enough prompts to cover a reasonable range of numbers, probably at least 1 through 999.

[benlangfeld]

Also, that to have i18n provide translation for numbers, we'll need to add enough prompts to cover a reasonable range of numbers, probably at least 1 through 999.

And this is because recordings of single digits don't compose cleanly for larger integers. Is that the point of this issue?

[bklang]

And this is because recordings of single digits don't compose cleanly for larger integers. Is that the point of this issue?

Yes