I was able to install an intermediate version, when it was around 60%.
I don’t know if I am not able to install the updated version, because I have an old version previously installed on my machine or if there is something wrong in the translation.
Thanks @mayura, I was able to locate the translation file. It’s looking great! Thank you for your contribution.
There is one minor typo in the file which is blocking it from loading (in the future, we may try and scan for syntax issues like this during the translation process): the entry SKBalloonOSKClosed has a stray & at the start which is causing the loader to fail. This should be removed, and then you should be able to install it.
Once you are happy with it, let me know and I’ll get the final version integrated into the Keyman source.
It should in theory be possible to install a font along with the package – you’d need to build the package manually (or using Keyman Developer) rather than relying on the version generated by the website. That means we’d be unable to include it in the downloadable locales because the downloadable locale file is currently a single package that bundles all the locales as a single file – which means that all users would receive the Noto Sans Kannada UI font even if they don’t need it, which I am loath to do.
So, in theory yes, but in practice not yet. It’s a good idea and perhaps we should document this as a feature request on GitHub.
FWIW, we are planning to revisit the localisation for all the Keyman products – we’ve got some work to do to improve the localisation of the newer products, as well as retire old infrastructure. We’ll probably spend a couple of sprints on that in the not-too-distant future.
Many fields such as S_OSK_FontHelper_MatchedFonts1 S_OSK_FontHelper_NoFonts1a S_OSK_FontHelper_PleaseWait1 S_OSK_FontHelper_PossibleFontsOnly1 S_OSK_Hint3a S_OSK_Hint4a
are not completely internationalized. They are broken sentences with something at the end will make it complete. It would be very different to phrase a sentence with the same meaning in other language. Instead we could have add the variable %0:s similar to how it is done in other places. This way localization can be done freely and natively.
In the Hotkeys tab in Keyman Configuration, this text can be used around keyboard and language names, if necessary, for example: “Activate [Korean KORDA] Keyboard” would put “Activate” into the Prefix and “Keyboard” into the Suffix. It’d be better to use format strings but they are not supported in the XSL transforms… these can probably be left blank.
The language setup dialog has been removed as of Keyman 10 as most of these tasks are now completely automatic. So all S_LangSetup strings should be removed (noted in issue 1200.
This string is a prefix to a keyboard name and goes with S_OSK_FontHelper_NonUnicode2, i.e. S_OSK_FontHelper_NonUnicode1 + <keyboard_name> + S_OSK_FontHelper_NonUnicode2.
This string can be left blank – we have used it for beta version products but don’t have that in place at present.
We don’t currently translate product names, which is fairly common practice in computing products (e.g. Windows, iPhone etc are not translated). I know other products do have their names translated e.g. Coca Cola. But at this point we won’t translate the name.
A deadkey is a prefix key, used typically in European layouts such as French or Spanish to type accented characters. The deadkey is used to indicate an diacritic mark and is typed before the base character to which it is attached. The name comes from typewriters, where deadkeys would not advance the carriage when typed so then the next base character would overstrike in the same location on the paper.
We use the term ‘hardware deadkey’ in the localisation file to differentiate between Keyman keyboard deadkeys and deadkeys provided by the Windows keyboard – perhaps that could be better defined!
When this option is selected together with use of a mnemonic layout, the deadkey will act as a plain accent (which can be triggered by deadkey + spacebar normally).