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 ns 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