Its deliberately kept. Considering English language knowing people want to learn Indic languages and for them not to confuse how to switch back from the Indic language to English, its kept as English string(untranslated)

pot is edited before pushing to translation so that those strings will not get translated.

That makes no sense at all since other keys is also translated.

Aside from that, as long as you use the gettext for localization framework, it's localized against current locale. given that we are on the situation where you are concerned, usually the whole translations on the desktop should appears in any Indic languages. do we really need to worry about it in that case? most cases I've ever seen for those who use multiple languages on the desktop is to use English locale as the base locale and set LC_CTYPE for the language what they want to learn.

In addition, people who speak English only is going to learn Indic would be wrong assumption. if the above concern is really an issue, I would suggest to show both strings, locale-based translated strings and English say or use an icon.

As you can see this project is already developed and no further updates to iok happened since long time. In the current code, I see no pot modification is happening as those strings are individual string values being copied as label value on that left lower corner button.

Do you want me to also have localized translated buttons for Tab, Shift, Enter, Caps, ESC ?

maybe you can see how eekboard implements.

FWIW I don't see any good reason that iok toggles masking/unmasking the language list when clicking "To English" button though. there should be still some improvements on UI, but anyway.

Its one of the requirement while developing iok that once people are using any layout and want to quickly type latin letters then there should be some toggle to switch from latin to non-latin and vice-versa.

Suggestions to improve UI is always welcome.

I think you should test just iok command and not its complete UI.
LANG=hi_IN.UTF-8 iok

When you run iok in its default mode, you need some way to toggle as people who don't want to see all the keymaps installed in language list.

I did. otherwise how come I know how iok behaves on them? :)

As I suggested some the above, there might be a lot of things can be learned from eekboard perhaps.

Anyway you should separately think the convenience for development/testing and for regular use on the UI implementation. that would has different goals and direction to satisfy the requirements. as you yourself said in the above comment, people usually don't want to see everything in the language list. to be honest, current UI on iok may be comfortable for developer or testers, but not for the end users.

eekboard-inscript need to manually specify the complete keymap file name without ".mim"

eekboard behaves similar for toggle from any inscript map to English and vice-versa.

and some other issue with eekboard for Indic characters.

How can displaying by default all the language list for a person who just want to use Hindi desktop be user-friendly?

One of the goal for iok development was to have a simple UI and not to show much more added functionalities by default for non-English locale.

Well, you are missing the point though, I should file a separate bug for UI improvements. mixing up this translation issue and UI may makes it complicated.

For "To English" button and possibly other translated keys already, I still have some objection to keep non-translated string there though, that would rather be better having the icon instead of the string perhaps, because assuming one who wants to use iok can read English would be wrong.
there should be a chance to learn Indic for those who don't know English anyway.

Ankit,
    Would you recommend translations for "English" "to English" key labels and other key labels say Tab, Enter. Shift, Caps, Backspace, Space ?

Tagoh is suggesting to have those button labels translated.

(In reply to comment #11)
> Ankit,
>     Would you recommend translations for "English" "to English" key labels and
> other key labels say Tab, Enter. Shift, Caps, Backspace, Space ?
> 
> Tagoh is suggesting to have those button labels translated.

In my opinion, we should let this to be decided by each individual translator for their language's translation. So, I would say, let these messages marked as "Translatable" and provide enough "Localization (or translation) comments" in order to provide a context to the translator. This will help translator to understand where these messages are going to appear and they can make a decision accordingly.

Having this approach followed, we can have variance for each individual language for translations, e.g.
1. language X translating all these messages
2. language Y transliterating all these messages
3. language Z translating and putting English within brackets
4. language A keeping these messages in English as it is

And I think having such results should be fine, as translators know their language and customers better than us.

Thanks!
Ankit

Thanks Ankit and Tagoh for your input. I will add those 2 strings and update the pot file in svn. Soon, I will release new iok and when I will build it in Fedora, I will close this bug.

Built in rawhide iok-1.3.13-1.fc17. Will build for F16 soon.

iok-1.3.13-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/iok-1.3.13-1.fc16

iok-1.3.13-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.