Re: string-freeze exception request: add translated strings to GOK

[Christian Rose <menthos gnome org>]

ons 2003-10-01 klockan 15.01 skrev Bill Haneman:
> We'd like to add some translatable strings to GOK.  The additions fall
> into two groups:
> 
> (1) mark g_warning strings for translation: we may be able to reduce
> this to a single string and re-use, but the patch below uses two
> different strings (more informative).

My personal opinion is that marking these g_warnings for translation
could wait until after you've branched, and only then be applied to
HEAD. The messages do have some issues (see comments below) and not all
modules even mark their g_warnings for translation at all, so while I
still am of the opinion myself that they should be translated
eventually, it doesn't seem like a terribly pressing issue warranting
string additions on the stable branch of gok.

That's just my opinion though.


> (2) add strings to support internationalization of some types of GOK
> keyboards which cannot currently be internationalized.  This is in
> service of gok i18n bugs 122117 and 122112.
>
> The strings in #2 won't be exposed to users until 2.6 unless the users
> customize their 'Compose' keyboards.  These strings are part of a set of
> fixes to improve GOK's internationalization generally (see bug #107200
> which these strings address, and GOK internationalization tracker bug
> #122112).

This seems like a nasty fix to add on the stable branch -- it's not
trivial and it seems it might open a whole can of bugs with issues that
haven't been considered once we actually get some translations of these
layouts, and thus it seems inappropriate to add it on the stable branch.
It's also not a regression, so I'm more comfortable myself with looking
forward to see this in GNOME 2.6 than seeing this added to the stable
branch.
And, as you say, it won't be exposed to users before 2.6 anyway, so I
don't really see why it should be added to the 2.4 stable branch.

Others might be of a different opinion though. If either Kjartan or the
relase team thinks (2) is ok, then I'm fine with it too, but not until
that happens.


> I attach the patch which we'd like to apply.  

Please see my inline comments below.


>  		if (m_XkbDescPtr == NULL)
> -		        g_warning ("keyboard description not available!");
> +		        g_warning (_("keyboard description not available!"));

Why not an uppercase initial letter like in the other warnings?


> +				g_warning (_("Your keyboard geometry cannot be determined"));
[...]
> +		g_warning (_("Your keyboard geometry cannot be determined!\n"));

I don't see why these messages need to be different.


> -	/* TODO: these strings are useless without localization, but string freeze prevents inclusion */
>  	gok_keyboard_add_keys_from_charstrings (pKeyboard, 
> -						"level 0|abcdefghijklmnopqrstuvwxyz1234567890-=[];'#\\,./",
> -						"level 1|ABCDEFGHIJKLMNOPQRSTUVWXYZ!\"3$%^&*()_+{}:@~<>?",
> -						"level 2|",
> -						"level 3|"); /* no level 2 or 3 in C locale */
> +						_("level 0|abcdefghijklmnopqrstuvwxyz1234567890-=[];'#\\,./"),
> +						_("level 1|ABCDEFGHIJKLMNOPQRSTUVWXYZ!\"3$%^&*()_+{}:@~<>?"),
> +						_("level 2|"),
> +						_("level 3|")); /* no level 2 or 3 in C locale */

This absolutely need a comment for translators(*), so that they know
what on earth this is about and how it should be "translated"


>  	 * the characters in these two strings should occur in the same relative order.
>  	 */
>  	gok_keyboard_add_keys_from_charstrings (pKeyboard, 
> -						"level 0|etaonrishdlfcmugypwbvkxjqz`1234567890-=\\[];'<,./",
> -						"level 1|ETAONRISHDLFCMUGYPWBVKXJQZ~!@#$%^&*()_+|{}:\"><>?",
> -						"level 2|\0",
> -						"level 3|\0"); /* no level 2 or 3 in C locale */
> +						_("level 0|etaonrishdlfcmugypwbvkxjqz`1234567890-=\\[];'<,./"),
> +						_("level 1|ETAONRISHDLFCMUGYPWBVKXJQZ~!@#$%^&*()_+|{}:\"><>?"),
> +						_("level 2|\0"),
> +						_("level 3|\0")); /* no level 2 or 3 in C locale */

The same here.

But to repeat myself again, I don't see any strong reason this needs to
be added to the stable branch.

(*)
http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#use-comments


Christian