Translation


#1

Hello,

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.


#2

Mayura, can you give me a link to your translation to make sure I have the correct one?


#3

https://secure.tavultesoft.com/keyman/support/locale/edit.php?KeymanLocaleID=125&NextTarget=


#4

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.


#5

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.


#6

Thank you. It is fixed now. I am able to install the translation.

There are few issues in the language, I want to make it as native as possible to the user. I will let you know once it’s ready to be integrated.


#7

Can I use a font which will be packaged with the keyboard as display font?

I am planning to use Noto Sans Kannada UI (123 KB) which has OFL 1.1 license as the display font.

If we can package that font with the Keyman installation. It would be great. If not, I will add in the language package, if it works.


#8

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.


#9

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.

Please look into it.


#10

“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?


#11

one more point, please make the localization flexible to change the window size and font size.

Window size and font size is huge constraint in localization.

I can see some codes in locale_en.xml to adjust the window size. I am sure if we can use this as customization while localization.

Ability to change font size and window size is needed while localization.


#12

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.

I’ve started to capture the feature points at https://github.com/keymanapp/keyman/issues/1200


#13

Please let me know the usage (how to use) of the below fields

S_Hotkey_Keyboard_Prefix
S_Hotkey_Keyboard_Suffix
S_Hotkey_Language_Prefix
S_Hotkey_Language_Suffix
S_LangSetup_Note
S_LangSetup_TitleInnerSuffix
S_OSK_FontHelper_NonUnicode1
S_BETA

They are all blank for English.


#15

&Name; is mapped to Keyman Desktop in English.
Can we translate this text?


#16

koDeadkeyConversion
Treat hardware deadkeys as plain keys

Advanced options - Base keyboard deadkeys are treated as normal keys

what is Hardware deadkeys?


#17

S_Hotkey_Keyboard_Prefix:
S_Hotkey_Keyboard_Suffix
S_Hotkey_Language_Prefix
S_Hotkey_Language_Suffix

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.


#18

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).