It would be great, if it were possible to obtain a city name in english with the localized one (not in within the same call) when using in other location.

Currently it's only possible to stations, because their name are no localized.

A function to obtain a country name of a location would be great as well.

If a contribution is welcomed, I can make a proposal

Moreover the current design pattern for obtaining locations and timezones (cp. https://wiki.gnome.org/GnomeOS/Design/Whiteboards/TimeZoneSelection) request the functionality to search in both languages, which is the normal case, every user  using a russian locale expects.

I already thought, how it could be implemented, my idea for the location database is to merge all single generated locale databases like Location.ru.xml with the english one Location.xml. In the all in one case there is nothing to do.

So...

for what concerns the serialization format, it was meant to store the name explicitly so that you could customize the name from the UI.
Also, it was meant to store "detached" locations, ie locations not in the db but created for example from geocode-glib data. In the end, this was never implemented, but it could be.
Indeed, the app could just build the serialization format itself after talking to geocode-glib, if it doesn't mind the instability of libgweather.

For the other issue, that is, the search in both languages, I believe the easiest solution would be to drop the translated databases completely. Instead, we would have the Locations.xml in English, we would look up the translation while parsing with regular gettext from the libgweather-locations catalog.
The problem is, gettext doesn't really like two domains the same project, so I don't know the build stuff required to make it work.

(In reply to comment #4)
> So...
> 
> for what concerns the serialization format, it was meant to store the name
> explicitly so that you could customize the name from the UI.
> Also, it was meant to store "detached" locations, ie locations not in the db
> but created for example from geocode-glib data. In the end, this was never
> implemented, but it could be.
Is it still desired? geocode-glib have its own location and place classes already.
> Indeed, the app could just build the serialization format itself after talking
> to geocode-glib, if it doesn't mind the instability of libgweather.
> 
> For the other issue, that is, the search in both languages, I believe the
> easiest solution would be to drop the translated databases completely. Instead,
> we would have the Locations.xml in English, we would look up the translation
> while parsing with regular gettext from the libgweather-locations catalog.
> The problem is, gettext doesn't really like two domains the same project, so I
> don't know the build stuff required to make it work.
one could just change location structure 

struct _GWeatherLocation {
    char **names or Glist names;

to store the names (in order or with locate name string) and parse almost the same way it's now
it will just require to modify the parser function 
char *
gweather_parser_get_localized_value (GWeatherParser *parser)
 
What do you think of the following feature, this would not break the existing api
the localized names could be retrieved using the same function
gweather_location_get_name(loc) which would return the locations name according to the current locale setting like:

old_locale = g_strdup (setlocale(LC_MESSAGES, NULL));
setlocale (LC_MESSAGES, "en_GB.UTF-8");

name = gweather_location_get_name(loc); // would give "Moscow"

setlocale (LC_MESSAGES, "de_DE.UTF-8"); 
name = gweather_location_get_name(loc); // "Moskau"

setlocale (LC_MESSAGES, "ru_RU.UTF-8"); 
name = gweather_location_get_name(loc); // "Москва" 

and so on, and if not found NULL is returned.

 amazing, I have seen your recent  changes, so it's now possible to use translation dynamically.
this is definetly the way to go!

Created attachment 250298 [details]
screenshot illustration a resulting locale mismatch due to broken serialization

sadly the current change breaks the localization of names totally, because there are many duplicate names and thus the msgctxt should be used additionally 

the function alone is not enough:
ret = (char*) dgettext ("libgweather-locations", (char*) untranslated_value);

Created attachment 250306 [details] [review]
patch proposal

Review of attachment 250306 [details] [review]:

I guess it makes sense.

(In reply to comment #10)
> Review of attachment 250306 [details] [review]:
> 
> I guess it makes sense.

-This way only the serialization can be fixed, because name is saved in english only as written in the location.xml
can I by the way push https://bugzilla.gnome.org/show_bug.cgi?id=585766

-the name in any supported localization can be obtained dynamically
 We wish this feature for clocks because we want to support city images later shared on flickr. and It would be appropriate to use the naming convention like berlin-germany.day.jpg, may be also useful for the weather app it could also share images of a city by rain sunshine and so on :-)

-the location-entry can be enhanced with two languages support as now required by current design (cp. Allans design mockup)

-minus "only" :-) only is a bit strong:-)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgweather/-/issues/119.