I have completed translation for Kannada for version 10.0.1100.0.
Trouble is, I had installed intermediate translation before. Now I am not able to install the updated version to test all the text.
Please check if there is any issue with the translation.
Also, I have tried to uninstall and reinstall Keyman several times, cleared the Keyman folder under “programdata”. Nothing is helping, I am not able to load the Kannada translation.
Please check if I have done something wrong in the translation.
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.
“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.”
When can we expect beta of version 11?
Should be continue to invest time in version 10 (localization, testing,), if it will be completely refactored anyways?
Even if we refactor the localization code in Keyman 11, we will continue to use the data from earlier versions so your investment in time is worthwhile.
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.
S_LangSetup_Note S_LangSetup_TitleInnerSuffix
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.
S_OSK_FontHelper_NonUnicode1
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.
S_BETA
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).
The issue on this topic has been resolved.
Respectfully, due to the inactiveness of the conversation, this topic is now closed for any further discussion.
Please feel free to create a new topic if there is any question or the issue persists.