After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 605700 - request for g_key_file_get_locale()
request for g_key_file_get_locale()
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gkeyfile
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2009-12-29 20:59 UTC by valmynd
Modified: 2018-02-06 15:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GKeyFile: add API for getting locale of a string (3.64 KB, patch)
2013-10-29 01:06 UTC, Allison Karlitskaya (desrt)
none Details | Review
GKeyFile test: add test for get_string_locale() (2.37 KB, patch)
2013-10-29 01:06 UTC, Allison Karlitskaya (desrt)
accepted-commit_now Details | Review
GKeyFile: add API for getting locale of a string (6.24 KB, patch)
2018-02-02 09:03 UTC, Philip Withnall
committed Details | Review

Description valmynd 2009-12-29 20:59:22 UTC
while g_key_file_get_locale_string () returns the entry, no matter if the locale string is "en" or "en_US", g_key_file_set_locale_string ().

example:
- my locale string is "de_DE.UTF-8", as returned by setlocale()
- i can call get_locale_string(kf, group, key, "de_DE.UTF-8"), which results in a valid string - just what i need
- after manipulating that string, i want to write that with: g_key_file_get_locale_string(keyfile, group, key, "de_DE.UTF-8", val)
- the file gets written, but what now? the desktop entry file, what this is about, didn't change after all
- i try the same thing with "de" instead, like g_key_file_get_locale_string(keyfile, group, key, "de", val) and yay, it works that way
- sadly, not so much luck with "de_DE". i'am on a workaround that is snipping anything behind the "_" charakter.

* sourcecode of what i'm working on: http://valmynd.git.sourceforge.net/git/gitweb.cgi?p=valmynd/valmynd;a=blob;f=main.vala;h=eba6b023bd684321ab88f887a2e0937a77c38654;hb=9d7e418
* example of a keyfile http://pastebin.com/f2f013a0
Comment 1 valmynd 2009-12-29 21:15:21 UTC
sorry for the typo mistakes :-/
Comment 2 valmynd 2009-12-29 23:24:23 UTC
i wanted to be more precise and came to an conclusion how to solve that for cases like mine: there should be a function within glib that gives me the present locale string for an entry. just like this:

gchar *g_key_file_get_locale (GKeyFile *key_file, const gchar *group_name, const gchar *key, const gchar *global_locale);

after calling that, i could use that for future g_key_file_set_locale_string() calls. this would solve it for me.
Comment 3 Matthias Clasen 2010-01-02 22:57:42 UTC
I'm not sure I understand what the problem is you are trying to describe here.
g_key_file_get_locale_string() does fall back to incomplete locale variants, while g_key_file_set_locale_string() just trusts you to pass in the exact locale string that you want to set the string for. Is that your problem ?

A short, selfcontained example showing your problem might help.
Comment 4 valmynd 2010-01-03 23:59:15 UTC
(In reply to comment #3)
> I'm not sure I understand what the problem is you are trying to describe here.
> g_key_file_get_locale_string() does fall back to incomplete locale variants,
> while g_key_file_set_locale_string() just trusts you to pass in the exact
> locale string that you want to set the string for. Is that your problem ?

you got it, this is the exact problem. i just copied the function names and missed to correct them afterwards, sorry.

> A short, selfcontained example showing your problem might help.

this is a modified example, i got from a dear helper from #gtk+ in irc.gimp.net (the original went offline, sadly):

http://pastebin.com/f2aead970

it shows, that the function does create a new entry, even if i want that entry changed within the current locale i have read through g_key_file_get_locale_string(). this IS a correct behaviour after all, i would just like to have a s/get/set function for that locale as described in commend #2

this is a workaround i did for my purpose (vala):

http://pastebin.com/f4aaa1469
Comment 5 Tobias Mueller 2010-07-15 11:39:05 UTC
Here's the code that's been pasted to those 3rd party sites:
/****
 gcc -o TestGLib.o test.c `pkg-config --cflags --libs glib-2.0` && LANG="de" ./TestGLib.o
****/

#include <glib.h>
#include <locale.h>

int main( int argc, char **argv )
{
    gchar *lang;
    GKeyFile *key;

    key = g_key_file_new();
    g_key_file_set_locale_string( key, "TMP GROUP", "tmp_key", "de", "test string" );
    g_key_file_set_locale_string( key, "TMP GROUP", "tmp_key", "de_DE", "other" );
    g_print( "%s\n", g_key_file_to_data( key, NULL, NULL ) );

    return( 0 );
}


	public string get_actual_locale(string key) {
		try {
			string temp = slocale.substring(0,5); // de_DE
			if(kf.has_key("Desktop Entry", key+"["+temp+"]"))
				return temp;
			temp = slocale.substring(0,2); // de
			if(kf.has_key("Desktop Entry", key+"["+temp+"]"))
				return temp;
		} catch (KeyFileError ek) {
			stdout.printf("%s", ek.message);
		}
		return slocale; // if translation was not present yet
	}
Comment 6 Allison Karlitskaya (desrt) 2013-10-29 01:06:36 UTC
Created attachment 258378 [details] [review]
GKeyFile: add API for getting locale of a string

g_key_file_get_locale_string() returns a translated string from the
keyfile.  In some cases, it may be useful to know the locale that that
string came from.

Add a new API g_key_file_get_string_locale() that returns the locale of
the string.
Comment 7 Allison Karlitskaya (desrt) 2013-10-29 01:06:41 UTC
Created attachment 258379 [details] [review]
GKeyFile test: add test for get_string_locale()

Add a testcase for the previous commit.
Comment 8 Philip Withnall 2018-02-02 08:42:31 UTC
Review of attachment 258378 [details] [review]:

::: glib/gkeyfile.c
@@ +2140,2 @@
 /**
+ * g_key_file_get_string_locale:

Needs to be added to docs/reference/glib/glib-sections.txt.

@@ +2143,3 @@
+ * @group_name: a group name
+ * @key: a key
+ * @locale: (allow-none): a locale identifier or %NULL

(nullable)

@@ +2147,3 @@
+ * Returns the actual locale from which the result of
+ * g_key_file_get_locale_string() or g_key_file_get_locale_string_list()
+ * came.

‘from which the result came’ is not a happy sentence way to construct. How about ‘Returns the actual locale which the result of … or … came from’.

@@ +2155,3 @@
+ * this function.
+ *
+ * Returns: the locale from the file, or %NULL if the key was not found

(nullable)

@@ +2158,3 @@
+ *   or the entry in the file was was untranslated
+ *
+ * Since: 2.40

2.56

@@ +2159,3 @@
+ *
+ * Since: 2.40
+ **/

`**/` is deprecated gtk-doc syntax; we use `*/` now.

@@ +2164,3 @@
+                             const gchar *group_name,
+                             const gchar *key,
+                             const gchar *locale)

Alignment seems a bit suspect here.

@@ +2167,3 @@
+{
+  gboolean free_languages = FALSE;
+  gchar **languages;

Would be better to have a:

gchar **languages_allocated = NULL;
const gchar * const *languages;

and assign languages = languages_allocated; in the allocated case. Free languages_allocated unconditionally.

@@ +2169,3 @@
+  gchar **languages;
+  gchar *result;
+  gint i;

gsize
Comment 9 Philip Withnall 2018-02-02 08:43:41 UTC
Review of attachment 258379 [details] [review]:

Yeah.
Comment 10 Philip Withnall 2018-02-02 09:03:38 UTC
Created attachment 367795 [details] [review]
GKeyFile: add API for getting locale of a string

g_key_file_get_locale_string() returns a translated string from the
keyfile.  In some cases, it may be useful to know the locale that that
string came from.

Add a new API, g_key_file_get_locale_for_key(), that returns the locale
of the string.

Include tests.

(Modified by Philip Withnall to rename the API and fix some minor review
issues. Squash in a separate test case commit.)
Comment 11 Philip Withnall 2018-02-02 09:09:05 UTC
I updated the patch to address the review issues, plus I also squashed in the tests (because having them in a separate commit doesn’t seem to make sense), and to rename the new API from g_key_file_get_string_locale() to g_key_file_get_locale_for_key(). I think the new name is less likely to get confused with the existing g_key_file_get_locale_string().

Putting it up here for review to get a second opinion on the new name.
Comment 12 Matthias Clasen 2018-02-06 15:48:32 UTC
Review of attachment 367795 [details] [review]:

Not sure it is a super-useful api, but +100 for adding a test.
Comment 13 Matthias Clasen 2018-02-06 15:48:51 UTC
Review of attachment 367795 [details] [review]:

Not sure it is a super-useful api, but +100 for adding a test.
Comment 14 Philip Withnall 2018-02-06 15:52:02 UTC
Pushed to master, thanks.

Attachment 367795 [details] pushed as 1574321 - GKeyFile: add API for getting locale of a string