When matching the target id in a phrase, if there is more than one match
we always use the final one. This allows us to easily specify a
default/wildcard entry that gets overridden by a target-specific one.
The list of targets was sorted alphabetically to ensure consistent ordering
from one run of the tooling to the next.
However, if a phrase contained both device-specific phrases as well as a
generic "feature" fallback, alphabetical sorting may screw things up, as
the "feature default" was no longer at the top of the list. This is
known to be an issue for LANG_TIME_SET_BUTTON and LANG_TIME_REVERT, but
may affect other phrases as well.
(To be blunt, we shouldn't be mixing feature and device-specific targets
in this context. The "feature default" should be removed in favor of
target-specific entries, but in this specific case it looks to be a
real PITA due to incomplete keymaps)
Consequently, work around this by sorting the target list within each phrase
based on the ordering in the master (ie English) language file.
Change-Id: Id32439c179a98663f414530fb36012f9b217c1b6
The tooling will always use the *final* match, which may or may not be
what is desired. Treat this as a bug, and complain appropriately.
However, there is a special case. The RTC set screen uses strings that
include the device button names. There should be an entry for the
specific device, but if not, we wanted to fall back to the string
specified by the 'rtc' feature flag as opposed to falling back to the
default, empty string.
To still support this, add a special "FALLBACK" value; If we end up
using this for a device, the tooling will treat this as a bug, and
complain accordingly.
This should fix FS#13615 and FS13616, and may introduce build failures
on targets that are missing appropriate entries. We'll see.
Change-Id: Ie78bb247f968e19d450a0fbf6e1177b6d01126a1
Languages:
* Get rid of leading space on LANG_ID3_VBR [ " (VBR)" ]
* Fix up sole user to insert the space programmically
updatelang:
* strip leading and trailing spaces on all phrases except VOICE_PAUSE
voice.pl
* Debug logging with UTF-8 output
* Explicitly delete tab character from voiced strings
Change-Id: Ie466793479ce15ce7a9553770583a070530e7afd
Instead of 'this phrase missing entirely [...]' followed by the
verbatim phrase copied from English, instead the message now
reads 'the 'PHRASE_ID' is missing entirely [...]. This allows
the warning to be self-contained.
Change-Id: I413c29e0c1f6616e74d875d197b34c4724330d67
Now no matter how [de]normalized the input strings are, we will
normalize them to the best of our ability in what we use.
This adds a dependencey for Perl's Unicode::Normalize.
Change-Id: I13e275692ea33a463b19f3a499ea06ce1acbb44a
Also corrected the 100% languages:
English, English-US, Chinese-Simplified, German, and Italian
(There is one Italian string I didn't know how to fix)
Change-Id: I958c6737810ad0199333d17fc092eab3120cef40
If someone submits an incomplete translation without a VOICE_LANG_NAME,
it will add the phrase but with a blank string. In subsequent runs,
the blank string will be treated as an error.. and copied from English.
Make it so that if it is blank, it stays blank.
Change-Id: Ib4a6645a5a52c9d0ff6dcfd0702c2a507bf8d756
* Voice generation script will create standalone .talk clips
* These talk clips will be included in the rockbox .zip file
* All .voice files will be included in the rockbox .zip file
* Added LANGUAGE_NAME for all languages in the nightly builds
This way, any voice pack installed will give you a the langauge
voiced in the browser, and if the voice file fails to load you
will get a natively translated error message.
Change-Id: I6b627a51746cd088d6e200666dd326ea2745f55f
...Unless it's the very first character (and will get stripped).
So detect and complain about this!
Change-Id: I5e333e8ee134160f64a67783b0d5aa564716d44e
We normally treat "same as English" as a translation errors that needs to be
corrected. However, many languages effectively use english words as-is, so
we need a way of distinguishing the "intentionally the same" situations with
our tools "automatically copying missing translated strings from English" to
avoid blank or missing UI strings.
The solution is to make sure these "intentionally same as english"
strings are actually different. This will be accomplished by prepending
'~' to the these strings. This special character is stripped from the
binary data files used by the player and the voice generation tools.
Change-Id: I90088cbd74de0e5cb9d65f75f26afe04f7e301bf
We do this by parsing out the format specifiers and making sure the
translation has the correct number, type, and order of specifiers.
Percent literals ('%%') are ignored.
Mis-matched formats can lead to much badness, so to be safe, use the
untranslated string instead and flag it as a problem on the translation
site.
Change-Id: Ib48c2e5c3502735b1c724dd3621549faa8b602b7
A lot of our translations have voice phrases that are identical
to English, even though they are translated in the display text.
In these scenarios, just use the translated text when generating
the voice files. These will still be flagged as problems by the
translation web site!
Change-Id: I39a9888eaad650e4c847cccc60bd89cf44ae150a
When a prase is translated but the voice is not, default to using
the translated phrase over the untranslated English voice
Change-Id: Ie2cb1c6d0c370f450586b8a4653f1a073f8aec9d
For example, English would say "231" as "two hundred thirty one" but
many other languages would say "two hundred one and thirty"
So, if VOICE_NUMERIC_TENS_SWAP_SEPARATOR is not an empty string, swap
the tens and ones position and use that string ("and" in the above
example) as the voiced separator.
Change-Id: I69f8064d44b3995827327cabae6ad352bf257d04
