Near-duplicate strings in programs ("Open", "_Open" etc.)

[Åsmund Skjæveland]

A suggestion for the applications of the future:

Many programs have lots of near-duplicate strings that differ only by
'_' or '.'. For example, both 'Open' and '_Open' are listed in most
programs. Also, many GConf description schemas have a 'long' and
'short' description that sometimes only differs in that the long ends
with a period, while the short one doesn't.

Can't these near-duplicates be merged somehow? For example
(pseudocode):

g_menu_item(item, _("_Open"));
g_menu_item_desc(item, strrep(_("_Open"), "_", ""));

I.e., instead of merking both "Open" and "_Open" in source as
translatable, mark only "_Open" and remove the "_" from the
translation as needed.

I'm not saying this is a huge problem, but the less duplicate strings,
the better.

-- 
Åsmund Skjæveland {
   [EMAIL PROTECTED]
}
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Near-duplicate strings in programs ("Open", "_Open" etc.)

[Funda Wang]

> Can't these near-duplicates be merged somehow? For example
> (pseudocode):
> 
> g_menu_item(item, _("_Open"));
> g_menu_item_desc(item, strrep(_("_Open"), "_", ""));
Not all the languages are using latin letters. For Chinese, we
translate "Open" as "ABCD", where  is Chinese characters,
and "_Open" will be "ABCD(_O)". It is obviously wrong just removing
"_" from the translations, because "Open" will become "ABCD(O)".

So, you suggestion does not fit non-latin languages.
__
Wanna know who is me?
http://my.opera.com/fundawang

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Near-duplicate strings in programs ("Open", "_Open" etc.)

[Clytie Siddall]

On 15/04/2006, at 7:43 PM, Funda Wang wrote:


Can't these near-duplicates be merged somehow? For example
(pseudocode):

g_menu_item(item, _("_Open"));
g_menu_item_desc(item, strrep(_("_Open"), "_", ""));

Not all the languages are using latin letters. For Chinese, we
translate "Open" as "ABCD", where  is Chinese characters,
and "_Open" will be "ABCD(_O)". It is obviously wrong just removing
"_" from the translations, because "Open" will become "ABCD(O)".

So, you suggestion does not fit non-latin languages.


The whole question of accelerator keys for non-single-key characters  
still needs to be resolved (before we organize any general way of  
treating strings with and without accelerators).


It's been discussed here, and on deb18n, and I don't think we got  
anywhere. :(


We need a way to use multi-key characters as accelerator keys, or  
many languages will have to continue doing what Funda describes:  
separating the translation from the accelerator. It's messy, and non- 
intuitive, but it's the only thing that works for now.


msgid "Hide"
msgstr "Ẩn"

I run out of "n"s very fast, and Ẩ is a dead-key-plus-vowel character.

Assuming the user will hit A for Ẩ will only work for a very small  
subset of users, and in any case, my language is mostly accented  
vowels, so even if we ignore the added diacritics, I have a, ă and  
â. I'm still going to run out of accelerators if I can only use one  
key for all three of these.


My language has 72 vowels, 12 separate vowels with 6 tones each,  
marked with diacritics. There are fewer consonants than in the Roman  
alphabet, and some consonants are used much more commonly than  
others. This doesn't work well for menus, either. :(


from Clytie (vi-VN, Vietnamese free-software translation team / nhóm  
Việt hóa phần mềm tự do)

http://groups-beta.google.com/group/vi-VN


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n