Re: Issues with keyboard accelerators
2009/3/30 Jorge González alor...@gmail.com: Hi all, I'm having some issues with keyboard accelerators. Recently some users opened bugs concerning the usage of keyboard accelerators with letters containing accents (ie.e _í, _á, etc); apparently they do not work, however I'm quite sure I tried them long ago and they did work. How are other teams that use accents (and such) dealing with this problem? Are you avoiding using keyboard accelerators with these letters? Should I report the bug to gtk? It is indeed a bug. For our case, we (Greek team) try to avoid those characters when setting accelerators for the reasons below. The source of the problem relates to your keyboard layout, and the fact that it may require dead keys in order to print characters such as áéäẽ, etc. Due to the dead key sequence, it is currently not possible to do things like Alt + dead_acute + a, the sequence is canceled as soon as Alt+dead_acute is pressed. If however you could get á in your keyboard layout by pressing a single key (that is, no need for dead key), then the accelerator would simply work. Is it a GTK+ bug or a Xorg bug? GTK+ could be modified so that when it sees _árbol, it would actually register it as if it work _arbol, so pressing Alt+a would simply work. The downside is that it would not be able to distinguish between áäãâà, etc. Would that be a realistic problem however? Would we want users to have to press Alt+dead_acute+a in order to get to the accelerator? With some layouts, you get dead_acute when you press AltGr+somekey, so the full keyboard sequence is Alt+(AltGr+somekey+a). I think I have seen a report about this but I cannot find it at gtk+, component: input-methods. It might actually be a report at freedesktop.org, so you might want to have a look there. The sequence Alt+dead_key+char might actually fail due to the X server cutting the sequence once the deadkey is pressed. Hope this helps, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Addition of new system-tools-backends strings to Damned Lies
Le lundi 30 mars 2009 à 14:32 +0200, Carlos Garnacho a écrit : Hi!, On dom, 2009-03-29 at 21:18 +0200, Claude Paroz wrote: Le dimanche 29 mars 2009 à 15:11 +0200, David Planella a écrit : Hi all, I just wanted to mention that after fixing this bug [1], there are a few new strings in system-tools-backends which should be added to Damned Lies. The problem is that s-t-b is not hosted on GNOME infrastructure. It used to have more translatable strings and the translation process was delegated to the Translation Project [3]. So someone has to prepare a pre-release containing a pot file, submit it to the TP, wait some days so as translators can submit their work, get back the translations in the s-t-b repo, and release a new s-t-b version. Considering the time taken by the patch in #528015 to be committed, I have some doubts about the speed of the above process :-( An alternative would be to delegate the translation to GNOME translators, and we could send a tarball with translations to the s-t-b (ex)maintainer. Carlos, any thought? I think that GNOME repos moving to git will be really helpful here. Back then, when I chose to use the TP, there were quite a lot of strings, quite prone to changes/additions, and s-t-b used CVS, so it quite looked like the best option. Nowadays such strings actually moved to frontends (gnome-system-tools) and the PolicyKit strings are quite unlikely to change often. So we could just set up a clone of s-t-b in GNOME git repos, and I could push translations there into the fdo one. Nice plan! Claude [3] http://translationproject.org/domain/system-tools-backends.html I do not know whether there will be time for that, but it might also be worth thinking of releasing a new version of s-t-b with these changes for 2.26.1, so that the translations are available to users. At least one distro (Ubuntu [2]) has already patched and released s-t-b. Hmm, if we're officially switching to git after 2.26.1, my proposal above wouldn't work for this... I you're willing to do this, you can send me translations (preferably using git-format-patch) and I'll apply them ASAP in order to make a release for 2.26.1 I'm sure sysadmins would be ok to create a s-t-b clone in the current git.gnome.org infrastructure, as other modules already did. I suggest you contact owen on #sysadmin pointing him on this thread. Then just tell us when the repo is set up. Thanks. Claude Regards, David. [1] http://bugzilla.gnome.org/show_bug.cgi?id=528015 [2] https://bugs.edge.launchpad.net/system-tools-backends/+bug/207677/comments/6 ___ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Moving GLib and GTK+ to git
Last week, I said that I'd like to get this done by the end of March, which is almost upon us now. Therefore, I'd like to ask everybody to hold off with committing to svn. While we are not quite ready to start the migration yet, it will begin sometime later today. So to avoid duplicate work, it would be best to wait with further commits to glib and gtk+ until the migration is completed. I'll send another email with checkout information, etc, when the conversion is done. See you all on the other side ! Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Request to create a new Language (Hausa Language)
Hi all, My name is Nasir Usman Imam, Member BOD Hutsoft Nigeria Ltd. I will like to start a new language by name HAUSA LANGUAGE, a language widely spoken in west Africa in the translation page of the gnome localisation page. I will like to create the team and also coordinate it. We have already started the translation of the project before the kick off of the FOSS Nigeria 2009 international conference http://fossnigeria.org/ I and my team will like to commit some translated .PO files to the SVN server as soon as i got the account open. I hope my request will be given due consideration. Thank You. Nasir Usman Imam, FOSS Nigeria, Nigeria ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request to create a new Language (Hausa Language)
Ysgrifennodd nui...@fossnigeria.org: My name is Nasir Usman Imam, Member BOD Hutsoft Nigeria Ltd. I will like to start a new language by name HAUSA LANGUAGE, a language widely spoken in west Africa in the translation page of the gnome localisation page. I will like to create the team and also coordinate it. I think this is very exciting. We already have a few Hausa translations, fwiw, but they're unmaintained: http://l10n.gnome.org/vertimus/gnome-desktop/HEAD/po/ha http://l10n.gnome.org/vertimus/gnome-menus/HEAD/po/ha http://l10n.gnome.org/vertimus/gnome-panel/HEAD/po/ha http://l10n.gnome.org/vertimus/gnome-session/HEAD/po/ha http://l10n.gnome.org/vertimus/metacity/gnome-2-26/po/ha http://l10n.gnome.org/vertimus/nautilus/HEAD/po/ha Thomas ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Issues with keyboard accelerators
On Mon, Mar 30, 2009 at 8:23 PM, Claude Paroz cla...@2xlibre.net wrote: Le lundi 30 mars 2009 à 11:07 +, Simos a écrit : 2009/3/30 Jorge González alor...@gmail.com: Hi all, I'm having some issues with keyboard accelerators. Recently some users opened bugs concerning the usage of keyboard accelerators with letters containing accents (ie.e _í, _á, etc); apparently they do not work, however I'm quite sure I tried them long ago and they did work. How are other teams that use accents (and such) dealing with this problem? Are you avoiding using keyboard accelerators with these letters? Should I report the bug to gtk? It is indeed a bug. For our case, we (Greek team) try to avoid those characters when setting accelerators for the reasons below. The source of the problem relates to your keyboard layout, and the fact that it may require dead keys in order to print characters such as áéäẽ, etc. Due to the dead key sequence, it is currently not possible to do things like Alt + dead_acute + a, the sequence is canceled as soon as Alt+dead_acute is pressed. If however you could get á in your keyboard layout by pressing a single key (that is, no need for dead key), then the accelerator would simply work. Is it a GTK+ bug or a Xorg bug? GTK+ could be modified so that when it sees _árbol, it would actually register it as if it work _arbol, so pressing Alt+a would simply work. The downside is that it would not be able to distinguish between áäãâà, etc. Would that be a realistic problem however? Would we want users to have to press Alt+dead_acute+a in order to get to the accelerator? With some layouts, you get dead_acute when you press AltGr+somekey, so the full keyboard sequence is Alt+(AltGr+somekey+a). I think I have seen a report about this but I cannot find it at gtk+, component: input-methods. It might actually be a report at freedesktop.org, so you might want to have a look there. The sequence Alt+dead_key+char might actually fail due to the X server cutting the sequence once the deadkey is pressed. Hope this helps, Yes, this helps :-) It would be cool if this could be at least documented in our Wiki. Thanks. I added the text at http://live.gnome.org/SimosXenitellis/KeyboardAcceleratorsAndAccents I did not see a canonical location on live.gnome.org to put the text. Where would it be good to move the page to? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Issues with keyboard accelerators
Hi Simos, Yesterday at 13:07, Simos wrote: GTK+ could be modified so that when it sees _árbol, it would actually register it as if it work _arbol, so pressing Alt+a would simply work. The downside is that it would not be able to distinguish between áäãâà, etc. Would that be a realistic problem however? Yes. With eg. Serbian Latin keyboard layout (and translation), š and s are totally different letters, as are č, ć and c (with distinct positions on the keyboard). Would we want users to have to press Alt+dead_acute+a in order to get to the accelerator? With some layouts, you get dead_acute when you press AltGr+somekey, so the full keyboard sequence is Alt+(AltGr+somekey+a). I think I have seen a report about this but I cannot find it at gtk+, component: input-methods. It might actually be a report at freedesktop.org, so you might want to have a look there. The sequence Alt+dead_key+char might actually fail due to the X server cutting the sequence once the deadkey is pressed. One can always modify a keymap to treat a dead key as another modifier that uses a new level (with XKB, you can have up to 64 levels, if I am not mistaken and/or confusing it with groups which you can have up to 8). We've tried doing something similar for Ctrl key for Serbian before, but that conflicted Gtk+'s special handling of Ctrl key. With dead keys, you should not have that many problems, but you might need to provide a new level for each of the dead keys. Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
