[libsoup] Created branch gnome-3-24
The branch 'gnome-3-24' was created pointing to: 390a9a2... Make http.conf deal with built-in mod_unixd ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-22
The branch 'gnome-3-22' was created pointing to: d00507d... vala: replace [Deprecated] annotations with [Version] ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-20
The branch 'gnome-3-20' was created pointing to: b97b9ef... 2.54.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-18
The branch 'gnome-3-18' was created pointing to: a801eb8... 2.52.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-16
The branch 'gnome-3-16' was created pointing to: b4120b5... Added Occitan translation ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-14
The branch 'gnome-3-14' was created pointing to: c8ff05b... SoupConnection: fix connection in TLS_HANDSHAKING event sig ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-12
The branch 'gnome-3-12' was created pointing to: 45605fe... Fix a memory leak in soup_cookie_jar_delete_cookie() ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-10
The branch 'gnome-3-10' was created pointing to: 5acf257... 2.44.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-8
The branch 'gnome-3-8' was created pointing to: 2a28ddf... 2.42.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-6
The branch 'gnome-3-6' was created pointing to: 91efda6... 2.40.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
network-manager-applet branched
network-manager-applet has branched for GNOME 3.6; the branch name is nma-0-9-6. I updated the jhbuild moduleset. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
libsoup now has translations
In git master, libsoup now has translations. (Only like 3 strings at the moment, but there will be more as the release cycle progresses.) -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-4
The branch 'gnome-3-4' was created pointing to: 127d3b0... 2.38.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-2
The branch 'gnome-3-2' was created pointing to: 6f12494... 2.36.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On 09/23/2011 07:58 AM, Olav Vitters wrote: I think that will add too much burden on the people who have to approve? I don't track RSS at all. Release-team gets a lot of freeze breaks and I want to be notified immediately, not after a delay. I need to see the comments that other teams make immediately as well as they're generally quite useful. RSS doesn't do that. Instead of keywords, we could just add bugzilla pseudo accounts for string-freeze-br...@gnome.bugs, ui-freeze-br...@gnome.bugs, code-freeze-br...@gnome.bugs. Then to request a break, just cc: the appropriate address on the bug along with a comment explaining why. Release/docs/i18n team members would just watch the appropriate address and so automatically get cc:ed on all the appropriate bugs. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-shell string freeze break request
I forgot that adding the menu item to enable the on-screen keyboard would add a new translatable string (Screen Keyboard) ok to add? -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-3-0
The branch 'gnome-3-0' was created. Summary of new commits: cc09f4c... 2.34.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Network status menu strings landed in gnome-shell
We just landed the new network status menu in gnome-shell, which contains new strings (many of which are copies of strings from network-manager-applet). This was already pre-approved by the release-team, so this is just a heads-up. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Network status menu strings landed in gnome-shell
On 03/16/2011 12:02 PM, Luca Ferretti wrote: 2011/3/16 Dan Winship d...@gnome.org mailto:d...@gnome.org We just landed the new network status menu in gnome-shell, which contains new strings (many of which are copies of strings from network-manager-applet). This was already pre-approved by the release-team, so this is just a heads-up. A translator comment for United Kingdom message could be appreciated :) http://git.gnome.org/browse/gnome-shell/tree/src/shell-mobile-providers.c#n77 Hm... Giovanni wanted to commit that code with no changes from the nm-applet code it was copied from, but I'm going to just remove the _() there; the string doesn't even get used in the shell anyway. BTW is it an iso (package) issue? Should be use a newer release? NM uses tzdata's iso3166 file (which calls GB Britain) instead of the iso-codes one (which correctly calls it United Kingdom). I think it also fails to translate all countries except the UK. To be fixed at some point... -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-2-32
The branch 'gnome-2-32' was created pointing to: a02f2f1... 2.32.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-2-30
The branch 'gnome-2-30' was created pointing to: 0df6a4c... Fix for proxies that close the connection when 407'ing a CO ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[libsoup] Created branch gnome-2-28
The branch 'gnome-2-28' was created pointing to: d45a4b1... Fix Request-Line in https over proxy ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [Fwd: Re: String additions to 'libgweather.HEAD']
Claude Paroz wrote: Dan, The fuzzy with Bordeaux is fixed, but there is still a problem with Wyoming which did not get back the State in United States msgctxt. Should be fixed now. Sorry. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [URGENT] wrong gconf key description in gnome-session
Ghee Teo wrote: Dan Winship wrote: Matthias Clasen wrote: Sounds fine to me to change the wrong key name. But is the description factually true ? The last time I checked, gnome-session would not bring nautilus back when I killed it, until I added the autorestart key to the nautilus desktop file. It's poorly-worded. It's supposed to mean even if you remove nautilus from your session, gnome-session will start it next time you log in anyway. You meant, nautilus will not restart itself before re-login itself. If it is, this is serious regression. No, gets restarted automatically if it exits and gets started when you log in even if it's not part of the session are completely independent, and the problem was that the required-components key was implying that it controlled the former, when actually it controls the latter. (Gets restarted when it exits is controlled by the autorestart key, as Matthias noted.) -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [URGENT] wrong gconf key description in gnome-session
Luca Ferretti wrote: Il giorno ven, 13/02/2009 alle 09.14 -0500, Dan Winship ha scritto: No, gets restarted automatically if it exits and gets started when you log in even if it's not part of the session are completely independent, and the problem was that the required-components key was implying that it controlled the former, when actually it controls the latter. (Gets restarted when it exits is controlled by the autorestart key, as Matthias noted.) Hmmm, so the change I've committed is wrong??!!??? List of components that are required as part of the session. (Each element names a key under /desktop/gnome/session/required_components). To be a required component of the session means that removing a required component from a running session (for instance killing related process), gnome-session will start it next time you log in anyway. It's... not totally wrong, but it's not great. The 2.24 text was: List of components that are required as part of the session. (Each element names a key under /desktop/gnome/session/required-components.) The Session Preferences will not normally allow users to remove a required component from the session, and the session manager will automatically add the required components back to the session if they do get removed. Besides the - - _ fix, I'd just change the end to will automatically add the required components back to the session at login time if they do get removed. (ie, add at login time) -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [URGENT] wrong gconf key description in gnome-session
Matthias Clasen wrote: Sounds fine to me to change the wrong key name. But is the description factually true ? The last time I checked, gnome-session would not bring nautilus back when I killed it, until I added the autorestart key to the nautilus desktop file. It's poorly-worded. It's supposed to mean even if you remove nautilus from your session, gnome-session will start it next time you log in anyway. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
libgweather string change that doesn't affect you
I just fixed #548630, which removed two strings from libgweather, and #549047, which added back a string (Guadalajara) that was present in 2.22 but had been removed in 2.23. Then I updated all of the affected translations (using the translations of that city name from 2.22). So this shouldn't actually affect anyone. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Fwd: major libgweather Locations updates
Kenneth Nielsen wrote: On another note, seeing the size of this change makes me wonder. It must have taken an immence development effort to complete this update, streching over quite some time, would it really have been so difficult to warn us back when you began and then to commit every once in a while so we could have had more time with some of the strings? I thought it was going to be committed sooner, relative to the freezes, but then the freezes ended up being a lot sooner than I had been thinking. As for committing every once in a while, that wouldn't have helped; the earlier stages diverged from 2.22 even more. Most of the work involved was getting the new Locations.xml.in to be *more* like the old Locations.xml.in, except in the places where the old Locations.xml.in sucked. We need to come to some agreement on this soon Sorry, I'd been under the impression that we already *had* come to an agreement (after no one responded to my last message). Most of the translators have not participated in this thread, so I don't have a sense if this is a few translators want the changes reverted or most of the translators want the changes reverted. I guess if it's the latter then maybe that's a different story. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: major libgweather Locations updates
Sorry about not getting back to this sooner. I talked with Vincent about this (with him wearing his libgweather maintainer hat, not his release team hat), and I think we agree that the possible scenarios are something like this, ranked from best to worst: 1. Keep new Locations.xml.in, all translation teams fully translate it 2. Keep new Locations.xml.in, translation teams translate at least the new locations in countries where their language is widely spoken 3. Revert to old Locations.xml.in, use existing translations 4. Keep the new Locations.xml.in, no new translations Right now we're somewhere around 4, but it's not a whole lot of effort to get to 2, which I think is all we need to target for 2.24; no one using the Arabic localization is going to notice if there are small towns in Denmark left untransliterated. We also agreed that it might make sense to remove libgweather (at least the po-locations part) from the translation statistics, for exactly that reason; it's not like with ordinary UI strings, where any user in any language is equally likely to encounter any string. So we're not planning to revert Locations.xml.in. However, we will also try to not make any more major changes to it in 2.24. (If people find things that are horrifically broken, or that are regressions from 2.22, we'll fix them, but if they find things that are just not-as-perfect- as-they-could-be, we'll wait.) -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: major libgweather Locations updates
Djihed Afifi wrote: First, are you absolutely sure this is stable now? I won't touch this until it is. No, that's why I suggested people should wait a week or so before making major effort at translating it. Because as people report problems, I'm going to try to make improvements. I am not sure what methodology was used to prune or consider cities. For the most part, it is the same as before; we list cities where there are weather stations. The only difference is that now: - We also try to include major cities that don't have their own weather stations - We try to have each location be a city name, rather than an airport name or something else - If there is a location in a small town, and there's a medium-sized city nearby, we try to name the location after the medium-sized city instead of the small town. (This depends on us having good data about the relative sizes of cities, so it works better in some countries than others.) Fundamentally, things are still driven by where there are weather stations reporting. I had a quick look at Arab cities in general and Algerian cities in particular. So as a first pass, you sould just be comparing to GNOME 2.22, rather than to the theoretical perfect list of Algerian cities. You'll find that the list hasn't changed all that much (and hopefully where it has changed, it's better now. Eg, Algiers has been added, Tamanrasset/Aguenna (a combined city and airport name) has now become Tamanrasset (just the city name), etc. Algeria also has a very odd population density. 80% of people live in 15% of the land. But more than half the cities in the file are Saharan cities. Yeah, so this is because that's where the weather stations are. From googling/wikipedia-ing, it looks like a lot of them are associated with oil fields. If they really are basically useless, we can remove them from the list. (Vincent and I were having this debate on IRC the other day, about a handful of weather stations in very very tiny towns (eg, ~100 people) in France. On the one hand, it seems better to keep them--maybe the computers at the oil field run GNOME? :) But on the other hand, more locations means more work for translators, so I can understand the desire to keep the list small...) The city choice was not made on population either. For countries where we have population data, all cities with population greater than 100,000 are included. However, we don't have population data for very many countries. We can fix this manually by adding cities to libgweather/data/major-cities.txt. In brief, some Algerian choosing cities, and looking under Algeria will be wondering how exactly were the cities chosen. I suspect the same will be true for many people around the world. Yes, but that was true in GNOME 2.22 too. This is a first step toward improving it. As for your question of what to do with suggested improvements, please don't make changes directly to Locations.xml.in at this time; put the fixes in a bug report instead. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: major libgweather Locations updates
Claude Paroz wrote: Le lundi 04 août 2008 à 07:37 -0400, Dan Winship a écrit : Dan, do you have criteria to include new cities? For example, for Liechtenstein, a very small country of 160 km2 and 35000 inhabitants, there is 11 cities. What's the use case? The vast Liechtensteinian GNOME hacker contingent? Important enterprise desktop sales among Lichtenstienian megacorporations? Hm... so basically this was the script being dumb. One of the criteria I was using to decide major cities was cities that are the capitals of top-level administrative divisions (eg, states provinces, etc), because our dataset has that information for most countries, but it doesn't have population information. This heuristic worked really well in some countries, but then in other places it looks like it's just filling Locations.xml up with crap... So I took out that rule and regenerated Locations.xml.in, and now 10 of those 11 cities in Liechtenstein are gone, along with 619 other cities around the world. (A couple dozen of those cities actually *are* major cities that we want to eventually put back, but we can fix those later.) -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: major libgweather Locations updates
Andre Klapper wrote: Am Sonntag, den 03.08.2008, 21:24 -0400 schrieb Dan Winship: I've just committed a huge update to libgweather's Locations.xml.in. From an i18n perspective, the big changes are that a lot of strings representing airport names, etc, went away and were replaced with actual city names. Also, many city names in some countries were replaced with better-localized/better-transliterated versions. Uhm. This has decreased all translations by 5-6% which is A LOT: Yup. But most of the new untranslated strings are either: (a) the names of minor cities that aren't going to have different names in different languages anyway (though I realize these still require transliterations in non-latin-alphabet languages) (b) the names of cities in countries where GNOME doesn't currently have many (or *any*) users (because in the places where there are lots of GNOME users, people had already gone through and replaced airport names with city names and added entries for major cities years ago, so there aren't as many changes there now). So while the translation stats are now much worse on paper, they're worse in ways that our current users probably won't notice. The reason we wanted to get this in for 2.24 is that the new autocompleting GWeatherLocationEntry works better if everything is based on city names, because it has the user typing their location in rather than picking it from a giant list, and they're not going to type the name of a random airport or geographical feature nearby, so with the old Locations.xml.in, it would be harder for people to find the right location. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
much smaller libgweather timezones update
Part two (of two) of libgweather string churn. I've just committed the patches to give us localized timezone names rather than using the America/New_York-style strings. Most countries now will just end up using the country name as the timezone name, meaning they're already translated. Most of the remaining strings are either very simple (Eastern Time) or else reuse the names of already-translated locations (Moscow Time, Western Kazakhstan) and so shouldn't be too hard to translate. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: major libgweather Locations updates
Andre Klapper wrote: #: ../data/Locations.xml.in.h:40 msgid Abilene Regional Airport #: ../data/Locations.xml.in.h:50 msgid Abumusa Island, Abumusa Airport #: ../data/Locations.xml.in.h:769 msgid Babelthuap Island, Babelthuap /Koror Airport #: ../data/Locations.xml.in.h:2301 msgid Cincinnati Municipal Airport, Lunken Field Is there a concept behind the different versions of listing an airport (commas, no commas) that I don't get? ;-) The closest there is to a rule is that if there's a comma, then everything on the same side of the comma as the word Airport is part of the airport name, and anything not on the same side probably isn't. Here's the situation: our primary source of weather station information is just the most godawful database in the world, with absolutely no consistency in naming conventions, ridiculous misspellings and typos, out-of-date names for airports (and even for cities in some places), etc. You can see my efforts to improve the situation here: http://svn.gnome.org/viewvc/libgweather/trunk/data/station-fixups.pl?view=markup In the case of the specific examples you gave, the names of the airports themselves are Abilene Regional Airport, Abumusa Airport, Babelthuap/Koror Airport (the weird spacing around the / is a bug), and Cincinnati Municipal Airport. The middle two are preceded by the name of the island where they are, which maybe I should be stripping out because the information probably isn't that useful. The last one is suffixed with the name of a specific area within the airport, which I should *definitely* be stripping out... (Note that these strings are only used to differentiate different weather stations within a city. Eg, someone living in Cincinnati can pick either Cincinnati Municipal Airport or Cincinnati / Northern Kentucky International Airport depending on which is closer to them, and get better weather reports that way.) -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: much smaller libgweather timezones update
Roozbeh Pournader wrote: Dan (and everybody interested in translating these), Just to bring to your attention that the Unicode CLDR standard provides localization patterns and best practices for user-friendly timezone names in user interfaces: http://www.unicode.org/reports/tr35/#Timezone_Names Yeah, we were going to use their data, but we decided against it. In particular, one of their design goals is to have all regions that share the same offset and DST rules end up having the same timezone name (eg, Central European Time, East Africa Time), because the CLDR timezone data is mostly concerned with doing strftime(), and so translating Europe/Stockholm and Africa/Tunis both to Central European Time makes it easy to compare timestamps between the two. But for us, saying Central European Time is bad, because it turns out that a lot of people in that timezone have never even heard of that name for it. So for libgweather's purposes, it's better to just say that Europe/Stockholm is Sweden Time and Africa/Tunis is Tunisia Time. More notes in the bug, particularly here: http://bugzilla.gnome.org/show_bug.cgi?id=529054#c6 FWIW, the arguments there don't apply as much to showing dates in the evolution calendar, so we may want to use the CLDR data there. (There's still the problem that AFAIK most distros aren't packaging the CLDR data, and that most of the CLDR timezone data isn't translated into many languages yet...) Disclaimer: Gnome Foundation is a member of the Unicode Consortium, and Behdad and I are our representatives there ;-) This also means that you find a fault with the (localized/original) data or the specification that you wish to be corrected, pass me and Behdad a note, we will contact the people in charge to correct them. OK. Well, I'm not sure this is really a fault. It's more of a use case that is a little bit outside what they're trying to cover. In order for us to be able to use their data, we'd need a flag in the metazone data distinguishing timezone names that really honestly are in common use (eg, basically 100% of Americans know about Eastern Standard Time) vs the timezone names that were invented for the tzdata or CLDR databases which people just *wish* were in common use. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
major libgweather Locations updates
I've just committed a huge update to libgweather's Locations.xml.in. From an i18n perspective, the big changes are that a lot of strings representing airport names, etc, went away and were replaced with actual city names. Also, many city names in some countries were replaced with better-localized/better-transliterated versions. This is unfortunately a huge amount of churn in an already-huge list of translatable strings. Two suggestions: 1) Search the po file comments for This is the capital of, which will let you find national capitals, which are presumably more likely than average to need special translations. Also, search for is the traditional English name to find cities that are called something different in English than they are in the local language, which usually also points to the need for a translation. 2) Other than that, wait a week or so (or more) before translating anything, and don't clean out the now-unused translations right away, because we'll be requesting some help from gnome-love which may result in some lame cities being removed and other ones being renamed, etc. Also, once GNOME 2.23.6 is out there, we're going to bump the intltool requirement to the latest version, which will let us add msgctxts to disambiguate duplicate names (eg the US state of Georgia vs the former Soviet Republic of Georgia). -- Dan PS - I'm not actually sure how to regenerate the files in libgweather/po-locations/ although some translators apparently know. Any hints? It seems like we ought to have a Makefile rule that does that... ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: help needed with non-US time zones for clock applet
Federico Mena Quintero wrote: On Mon, 2008-04-07 at 12:05 -0400, Dan Winship wrote: - Mexico: 8 timezones, many locations, not divided into states, so I didn't even try sorting them out. Everything got America/Mexico_City Fixed all of Mexico (added states and capitals). I'm not sure if I got the Mexico/BajaNorte and Mexico/BajaSur timezones correctly; they are in my /usr/share/zoneinfo, but check_timezones.sh said they were invalid. tzdata includes lots of backward-compatibility links so as to not break systems using old names, but check_timezones.sh only accepts the current zone names (from zone.tab). In this case, Mexico/BajaNorte - America/Tijuana, and Mexico/BajaSur - America/Mazatlan. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for two string changes in libgweather
Vincent Untz wrote: + http://bugzilla.gnome.org/show_bug.cgi?id=525761 Louisiana consistently misspelled as Lousiana I'd like to at least fix the second one in gnome-2-22, this also includes a search and replace for Lousiana in all po files, that Dan has already done. Is this okay? Specifically, most languages either didn't translate it, or already had the correct translation/transliteration despite the misspelled original. Buthe following .po files had transliterations where I couldn't tell if they were transliterations of the right or wrong spelling: ar.po, as.po, bn.po, bn_IN.po, dz.po, fa.po, gu.po, hi.po, kn.po, lt.po, mai.po, ml.po, mr.po, ne.po, or.po, pa.po, si.po, ta.po, te.po, th.po But I updated the msgid strings, so worst case is that those languages just continue to have a typo, rather than entirely losing their translation for that string. -- Dan PS - If we want to batch up Locations.xml string breaks, there's also this: country _nameUnited States Minor Outlying Islands/_name iso-codeUM/iso-code location !-- FIXME: Pago Pago is in American Samoa, which is not part of the United States Minor Outlying Islands. Fix on head after branch, when we can add new strings. -- _namePago Pago/_name ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: help needed with non-US time zones for clock applet
Lucas Rocha wrote: Hi Dan, 2008/4/7, Dan Winship [EMAIL PROTECTED]: - Brazil: /usr/share/zoneinfo/zone.tab lists 15 zones. I did not even bother trying to figure them out, and assigned the whole country to America/Sao_Paulo. There are 4 timezones in Brazil. Have a look at: http://wwp.greenwichmeantime.com/time-zone/america/brazil/ Right, sorry, I didn't explain this fully in the email... (I'd spent a week dealing with it, so it was all obvious *to me*... :). The issue is that in order for the clock applet to be able to guess the right timezone for a location, someone has to go through and figure out which locations are in which timezones. Eg, Brazil has 44 cities (or at least locations) listed: country _nameBrazil/_name iso-codeBR/iso-code tz-hintAmerica/Sao_Paulo/tz-hint location _nameBagé/_name codeSBBG/code coordinates31-21S 054-07W/coordinates /location location _nameBelém/_name tz-hintAmerica/Belem/tz-hint codeSBBE/code coordinates01-23S 048-29W/coordinates /location city _nameBelo Horizonte/_name location _nameConfins Airport/_name codeSBCF/code coordinates19-56S 043-56W/coordinates /location /city ... You can see here that I cleverly guessed that Belém is in the America/Belem timezone, but most of the locations don't have a specific guess, and so they're going to inherit the default from the country entry. To get better guesses, someone would have to go through all 44 location entries and assign the right tz-hint to each one (using maps and google results, etc, to figure out which timezone each city is in). In the US, this was made a little bit easier by the fact that the Locations file already splits the US up by states, and most states are entirely in a single timezone, so I could just assign one tz-hint to the whole state. So if Brazil also has states or provinces, and if the time zone divisions fall mostly along the borders of those states/provinces, the easiest solution might be to split it up according to those first, and just assign tz-hints to the states. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
help needed with non-US time zones for clock applet
(Specifically, if you live in [or are knowledgeable about] AR, AU, BR, CA, CN, CD, GL, ID, KZ, MY, MX, RU, UA, or UZ, please read this. Thanks :) Vincent has just committed the patches to fix the clock applet guesses the wrong timezone bug, but this relies on libgweather/data/Locations.xml.in having the correct timezones listed for various places. For large countries that span multiple timezones, it takes some work to get this right. I spent a while getting the US right, and I did some investigation on most of the others, but there are still places where the information is wrong (especially in the non-English-speaking countries, which it was harder for me to find reliable information about). Specifically: - Argentina: /usr/share/zoneinfo/zone.tab lists 11 zones, though Wikipedia claims that there is only a single zone for the entire country. It's possible that the other 10 zones reflect historical distinctions that are no longer relevant. I assigned the whole country to America/Argentina/Buenos_Aires. Is this right? - Australia: I assigned a timezone to each state in AU, but /usr/share/zoneinfo/zone.tab has multiple zones for most states, so some location entries on the edges of states may need to override the tz-hint inherited from their state. - Brazil: /usr/share/zoneinfo/zone.tab lists 15 zones. I did not even bother trying to figure them out, and assigned the whole country to America/Sao_Paulo. - Canada: I assigned a timezone to each state, and split things up further within states in a few cases where it was easy to distinguish timezones by longitude. Still needs some tweaking around the edges. - China: 5 timezones listed, but everything I've seen says that only Asia/Shanghai is still in use. Right? (Taiwan and Hong Kong are listed separately.) - Democratic Republic of the Congo: 2 timezones. I assigned the whole country to Africa/Kinshasa - Greenland: 4 timezones, several locations. I assigned the whole country to America/Godthab - Indonesia: 4 timezones, somewhat guessable based on longitude. Probably not 100% right though - Kazakhstan: 5 timezones. A few of the locations matched the name of a timezone, but the remaining ones got defaulted to Asia/Alamaty. - Malaysia: 2 timezones on widely separated islands, so I think I got these right just going by longitude. - Mexico: 8 timezones, many locations, not divided into states, so I didn't even try sorting them out. Everything got America/Mexico_City - Russia: 15 timezones, many locations. Everything got Europe/Moscow. - Ukraine: 4 timezones, Everything got Europe/Kiev - Uzbekistan: 2 timezones, Everything got Asia/Tashkent If you can provide better data for any of these, please check out libgweather, add tz-hint lines to the appropriate country, state, or location entries in data/Locations.xml.in (the tz-hint has to come immediately after the _name; run make check when you're done to validate the XML), and submit a patch to the libgweather product on bugzilla.gnome.org. Thanks. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
