GNOME Bugzilla – Bug 754210
App details: Category label needs left pointing arrow in RTL locales
Last modified: 2015-09-08 10:46:43 UTC
The label label_details_category_value uses the "Category → Subcategory" format. The arrow should point left in the right-to-left locales. The fix seems to be trivial but it is not. The category value is prepared in the menu-spec-refine plugin, function gs_plugin_refine_app_category(). This function has no knowledge about the text direction of the destination widget. There are some possible solutions but I don't really like any of them: 1. Provide the text direction information to the plugin. Really bad, requires breaking the API of the plugins for this single application. 2. Make the "%s → %s" format string translatable. Requires breaking the string freeze. Not perfect because one can force the text direction of a widget independently on the current locale. Also I'm not sure if the translators like the C format strings. 3. Replace the "→" substring with "←" just before setting the string displayed by label_details_category_value. Sound too tricky but also seems to be working and the least harmful. What do you think?
(In reply to Rafal Luzynski from comment #0) > The label label_details_category_value uses the "Category → Subcategory" > format. The arrow should point left in the right-to-left locales. > > 1. Provide the text direction information to the plugin. Really bad, > requires breaking the API of the plugins for this single application. > 2. Make the "%s → %s" format string translatable. Requires breaking the > string freeze. Not perfect because one can force the text direction of a > widget independently on the current locale. Also I'm not sure if the > translators like the C format strings. > 3. Replace the "→" substring with "←" just before setting the string > displayed by label_details_category_value. Sound too tricky but also seems > to be working and the least harmful. > > What do you think? I think the plugins should provide the information (ie the category+subcategory pair), and leave the formatting to the frontend. Making the "%s -> %s" string translatable is a perfectly fine solution for the formatting part. You don't have to worry about manually overriding the text direction, we don't do it.
Created attachment 310388 [details] [review] Change the type of menu_path from gchar* to gchar** and format the path correctly I'd like to mention that the bug has been spotted and the solution has been suggested by Elad on IRC.
Created attachment 310866 [details] [review] Change the type of menu_path from gchar* to gchar** and format the path correctly Same as above but rebased.
Created attachment 310877 [details] [review] Change the type of menu_path from gchar* to gchar** and format the path correctly Rebased again.
Review of attachment 310877 [details] [review]: I think the approach to let UI code deal with the arrow direction is good. Plugins can't really do that since they have no idea about widgets and text directions. Some thoughts I had while reading the code: 1) If you are dealing with arrays of strings, just go with 'gchar **' everywhere. Right now you have a mix between 'gchar **' and 'const gchar **' -- adding a const there doesn't make it any safer if it forces you to use a typecast. 2) I am not sure the data structure chosen is the best: a list might be more appropriate since it naturally allows a different number of elements. In some cases we might have only the parent category; in other cases it could be deeper. const gchar *menu_path[] = { NULL, NULL, NULL }; and static const gchar *EMPTY[] = { "", NULL }; ... doesn't strike me as very elegant; a list would probably fit in more naturally.
Created attachment 310885 [details] [review] Change the type of menu_path from gchar* to gchar** (not const gchar**) After the IRC conversation: const dropped everywhere, otherwise not changed.
Pushed to master with a couple of fixes, thanks.