I really wonder why the code comment says.
case NUM2_THOUSANDS_VAR2: // lang=cs,sk
and option 4 was used for Czech, and this is not the case when this
option fits the language, just the opposite.
it reads 10000000 as 10000, 11000000, as 11000, and so on
almost the same problem was in the Russian language, only it consisted
in the fact that the var_1 itself was not made correctly. And here the
variant is commented on as the one that is used in the Czech language,
but it is not used there. And the worst thing is that everyone does not
pay attention to it, well, it reads the wrong number, well, okay.
- fix "здж" > "ждж" rule, fix test for it
- add rules for "б г д дз дж з" at the end of words
- added tests for new rules
- add devoiced rules conversion and tests
- languages.md: fix the Belarusian language name
fix "здж" > "ждж" rule, fix test for it
add rules for "б г д дз дж з" at the end of words
add devoiced rules conversion
add some words to vocabulary
added tests for new rules
This fixes the intonation in Latin American Spanish questions, removes the phoneme replacement (T to s) because it is already included in phonemes es_la. It also eliminates the line languaje es 6, because when the voice is in the dialect of Spain and it automatically changes to the dialect of Latin America, it does not return to the dialect of Spain.
When compile from read-only data bundle (shipped within iOS/macOS app),
we can't write compile_report file.
The simplest solution is to (almost) silently discard it.
This fixes the intonation in Latin American Spanish questions, removes
the phoneme replacement (T to s) because it is already included in
phonemes es_la. It also eliminates the line languaje es 6, because when
the voice is in the dialect of Spain and it automatically changes to the
dialect of Latin America, it does not return to the dialect of Spain.
Note: this doesn't fix actual problem for some of the older devices.
Unfortunately i don't have devices with os version below than android 7,
so am not able to test.
Sergei B