[mutter] Created branch gnome-3-2
The branch 'gnome-3-2' was created pointing to: acc4e03... Updated Vietnamese translation ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-shell] Created branch gnome-3-2
The branch 'gnome-3-2' was created pointing to: bba5198... Updated Spanish translation ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[resend] freeze break: confirmation dialog for extension installation
[ sent to gnome-18n last time, resend with the correct address ] As part of the work for extensions.gnome.org we've added a way to have the extensions.gnome.org website trigger downloading and installing an extension via a browser plugin. (The browser plugin and the download are locked to extension.gnome.org.) One thing that I pointed out in review was that I thought it was important to have an obviously client-side dialog before downloading and installing an extension - to make it clear to the user what is going on, and catch any funny business is going on. (E.g., XSS exploit on shell.gnome.org allows someone to script the plugin to download an extension they've snuck past code review.) https://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00242.html Adding this dialog requires a string freeze break to add the strings: Download and install '%s' from extensions.gnome.org? Install (First string still under discussion, but will be something like that.) Current patch on: https://bugzilla.gnome.org/show_bug.cgi?id=658612 Thanks! - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Those darn gdk-pixbuf .po file conflicts
Anybody jhbuilding GNOME will have run into problems with .po file conflicts in gdk-pixbuf, where building it causes local changes that conflict with updates from translators. Finally got annoyed enough to track down the problem. The unique characteristics that gdk-pixbuf has that causes these problems are: * It uses the upstream gettext Makefile.in.in not the GLib Makefile.in.in or the intltool Makefile.in.in * The .pot file isn't checked into Git The upstream Makefile.in.in is designed so that when the .pot file isn't there, it's generated, and the .po files are updated a single time. (The upstream Makefile.in.in also has another incompatibility with the GNOME internationalization workflow - it runs update-po on 'make dist') Possible fixes: A) Check in a .pot file. But this leaves the 'update-po on dist' problem. [This is the state of affairs of Clutter] B) intltoolize gdk-pixbuf, even though it doesn't need anything, so we get a non-annoying Makefile.in.in. [This is the most common thing in GNOME probably] C) Don't intltoolize gdk-pixbuf, but check some better Makefile.in.in into git so autopoint doesn't replace it. [This is the state of affairs in GTK+. Just copying the Makefile.in.in from GTK+ would presumably work fine.] B) is probably cleanest; I don't know if it will cause problems for people [cross]building gdk-pixbuf with mingw or building on OS X. I haven't suggested going back to glib-gettextize, since that's been something people have been trying to get away from. - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[mutter] Created branch gnome-3-0
The branch 'gnome-3-0' was created pointing to: 5eb8aa6... Bump version to 3.0.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-shell] Created branch gnome-3-0
The branch 'gnome-3-0' was created pointing to: 249f26d... Bump version to 3.0.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Code freeze break request for gnome-shell
On Thu, 2011-03-24 at 22:54 +0100, Luca Ferretti wrote: Il giorno mer, 23/03/2011 alle 21.55 +0100, Kjartan Maraas ha scritto: this._errorMessageLabel.set_text(_(Sorry, that didn\'t work. Please try again.)); Sorry for the late reply, I've seen this change was yet committed, but this message is really really really hard to translate. That what?? Could you please at least add a translator comment, in order to help us to provide an optimal translation/adaptation? David Zeuthen would have the best idea whether some useful comment is possible, since this is from the PolicyKit authentication dialogs. David? - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Code freeze break request for gnome-shell
On Wed, 2011-03-23 at 21:55 +0100, Kjartan Maraas wrote:
Hi.
Found some strings that weren't marked for translation in the correct
way in gnome-shell.
Patch attached...ok to commit?
OK with me to commit, except for the pointed out _('') which should be
changed to and not translated at all.
- Owen
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
String freeze break? corrupt sentence in mutter GConf schema
https://bugzilla.gnome.org/show_bug.cgi?id=645224 Determines whether workspace switching should happen for windows on all monitors or only the primary window. Should be: Determines whether workspace switching should happen for windows on all monitors or only for windows on the primary monitor. This string does not appear in the UI anywhere, you'd have to install and run gconf-editor to see it. So the main advantage of fixing it would be to avoid translators having to translate a nonsense sentence. - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Cantarell font
Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: To: Lucian Adrian Grijincu lucian.griji...@gmail.com The font is quite limited with respect to character coverage. For example it does not have all characters required for the Romanian language (I've recently added those characters and sent a message to the maintainer). I suggest the other language teams see if the font has support for all characters needed for their language. I see now why text in my laptop looks crappy (I'm testing Vietnamese version of gnome-shell). Any way to set default font per locale? Bit in a hurry at the monent, so I'll quote a relevant IRC conversation from yesterday that hopefully points you in the right direction. Let us know how it turns out. This was in the context of discussing the fontconfig snippet installed by the Fedora Cantarell package which was making it part of sans-serif which we didn't want, and what should be in there instead. owen cosimoc: we do need a fontconfig snippet owen cosimoc: the current plan is to make Cantarell inherently a weak binding so that if you specify Cantarell then it will get reordered behind stuff in sans-serif if it doesn't support the current language cosimoc owen, right now if I parse that snippet correctly, all it does is setting cantarell as default for sans-serif in the whole system cosimoc owen, which breaks KDE on fedora owen cosimoc: I'm saying, we need *some* snippet, not that we need *that* snippet cosimoc owen, oh fair enough :) mclasen cosimoc: can you try to figure out what snippet we might need ? cosimoc mclasen, my guess is we don't need any until we have the weak binding thing owen mentioned sorted out owen cosimoc: if someone is goign to modfiy the cantarell package, they really should try to come up with the weak Feb cosimoc owen, I'm the package owner so I guess it's my turn to learn how fontconfig works cosimoc: I think that what you need to do is to match on the Cantarell family name, and then replace it with the Cantarell family name, but as a weak binding owen match target=pattern owen test qual=any name=familystringCantarell/string/test owen edit name=family mode=assign binding=weakstringCantarell/string/edit owen /match owen cosimoc: the test to see whether that works is that owen pango-view --language=vi --font 'Cantarell 12' --text 'Nguyễn Thái Ngọc Duy' owen should show that name all in Deja Vu instead of having a ransom-note mix of Deja Vu and Cantarell owen (that's the GNOME Vietnamese translator's name) I apologize for using your name there - it was just the first Vietnamese text I found opening a .po file :-) - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, 2009-04-02 at 16:56 -0400, Owen Taylor wrote: On Thu, 2009-04-02 at 22:45 +0200, Olav Vitters wrote: On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: I've got a local branch with the rebased client-side-windows work. However, I am unable to push it to git.gnome.org due to the pre-commit hooks: The following translation (.po) file appears to be invalid. (When updating branch 'client-side-windows'.) po/af.po The results of the validation follow. Please correct the errors on the line numbers mentioned and try to push again. stdin:90: keyword msgctxt unknown stdin:90:8: parse error . Checking http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we have: # gettext-0.14.6 on git.gnome.org isn't new enough to handle # features such as msgctx # dash_c=-c dash_c= So a gettext update should be done. CC'ed gnome-sysadmin. Upgrading the system gettext to a radically different version isn't something that I want to do. My plan here is to create an RPM with just the gettext utilities that installs in /usr/lib/gettext17 or something. (BTW, I temporarily disabled the hooks so Alex could push his branch.) I've now gone ahead and done this - there is a statically linked version of gettext-0.17 in /usr/libexec/gettext17 that the pre-receive check uses now. I've also reeneabled -c, so it should be doing a full set of checks. Let me know if any problems show up. - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, 2009-04-02 at 22:45 +0200, Olav Vitters wrote: On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: I've got a local branch with the rebased client-side-windows work. However, I am unable to push it to git.gnome.org due to the pre-commit hooks: The following translation (.po) file appears to be invalid. (When updating branch 'client-side-windows'.) po/af.po The results of the validation follow. Please correct the errors on the line numbers mentioned and try to push again. stdin:90: keyword msgctxt unknown stdin:90:8: parse error . Checking http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we have: # gettext-0.14.6 on git.gnome.org isn't new enough to handle # features such as msgctx # dash_c=-c dash_c= So a gettext update should be done. CC'ed gnome-sysadmin. Upgrading the system gettext to a radically different version isn't something that I want to do. My plan here is to create an RPM with just the gettext utilities that installs in /usr/lib/gettext17 or something. (BTW, I temporarily disabled the hooks so Alex could push his branch.) - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
On Sun, 2008-01-13 at 21:13 +1300, Callum McKenzie wrote: I have a version of the gnome-applets code base that uses an external version of libgweather. I would like use this for the 2.21.5 release, so I'm asking if anyone has serious objections. Obviously this relies on Federico getting a tarball release of libgweather out the door (I'll be making my decisions at approximately 9am UTC on the 14th of January, if a release isn't done by then I will wait - possibly until 2.23 since we're getting on in the cycle). The effects this should have: i18n: No new strings, but some files with strings and the massive Locations.xml are moving. I think everything has been migrated properly, so translators should merely have to point their tools at a new place. Documentation: None, there is no UI (although the gweather applet location selection UI may eventually be migrated) and the API isn't actually documented. Bugzilla: Bugs about locations and the like will almost certainly end up getting filed against the gweather applet rather than libgweather. This is probably something we'll just have to live with - its the same with all libraries. In principle this shouldn't be a major change since it is effectively splitting an existing code-base in two rather than introducing a new dependency. However, I don't want to do anything without asking first. Current SVN trunk has the relevant code - although I'm prepared to revert (I managed to create a branch with the code and then commit the same code to trunk). Comments, criticisms? I'm slightly concerned by this ... libgweather does something pretty interesting (to a small set of consumers) but the API is no way ready for any sort of freezing. It has serious namespace and memory management issues, among other things. I don't think there is any proposal here to make libgweather part of the platform, but a) is there clear messaging about the API status? b) how would a transition to an incompatible new version be handled? - Owen signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
On Mon, 2008-01-14 at 08:56 -0500, Matthias Clasen wrote: 2008/1/14 Owen Taylor [EMAIL PROTECTED]: Comments, criticisms? I'm slightly concerned by this ... libgweather does something pretty interesting (to a small set of consumers) but the API is no way ready for any sort of freezing. It has serious namespace and memory management issues, among other things. I don't think there is any proposal here to make libgweather part of the platform, but a) is there clear messaging about the API status? b) how would a transition to an incompatible new version be handled? Pretty much like for any other instable api, I think. Users will have to check for a version they support and will have to be ported. Do you want us to do the -DI_SWEAR_I_KNOW_LIBGWEATHER_IS_UNSTABLE dance ? That is easy enough, if you think it helps. While that dance seems annoyingly pointless at times, I think it does serve some small purposes: - Everybody who compiles the modules using the unstable API sees it repeatedly and it hopefully sinks into the unconscious - It can be pointed to when people start complaining after an API break. - Owen signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: RTL support in Gnome
On Wed, 2007-01-17 at 14:46 -0500, Behdad Esfahbod wrote: On Wed, 2007-01-17 at 13:26 -0600, Shaun McCance wrote: Unfortunately, gnome-i18n has already become the de facto list for l10n, so naming a new i18n list would be tricky. gnome-i18n-devel? And how would this differ significantly in practice from gtk-i18n-list? - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Thu, 2005-10-06 at 19:57 +0200, Christian Rose wrote: The only thing needed for the translation status pages to be hosted at the real, live gnome.org servers is for someone to figure out what kind of CPU/memory/disk resources it needs, and is prepared to help set it up, or at least give sufficient instructions for having it set up. So what's the required configuration? [EMAIL PROTECTED]:/srv/l10n # du -hs . 6.9G. and the process takes near 4 hours with an AMD Sempron(tm) 2800+ and 768MB of RAM With more RAM and faster CPU the process should be also faster. The main problem here is the hard disk I/O that's why we had to move it outside widget the first time, the server load was really high. widget has since then been replaced by window. window.gnome.org is a dual Xeon 2.8 GHz server with 2 GB memory and RAID1 SCSI disks. This should be doable, right? Something that takes 4 hours of CPU time on window (a day?) probably isn't a huge deal ... window isn't terribly CPU-bound currently... and the process could be niced down. But if it's doing significant disk work - so ejecting stuff out of cache, then it's going to impact all bugzilla users, all anoncvs users, all people accessing www.gnome.org etc. window isn't really a good place to run intensive jobs, because so much is going on there. In any case, I wouldn't expect things to run faster on window than on Carlos's machine ... window is a bigger/faster machine, but it's no monster, and it's a heavily loaded bigger/faster machine. Disk space is rather tight on window too, though 7 gigs (added to /etc/rsyncd/backup.exclude appropriately) shouldn't be a big problem if we keep track. Things to do: - Try running it on window, see if it really takes 4 hours, or 2 hours. (30-45 minutes might be an OK time for an intensive task to churn.) - Get someone to look at optimizing it. You can do an incredible amount of work in 4 hours these days ... if this task is taking 4 hours, it's being done inefficiently. (Not volunteering) - If it really is that intensive, it's not optimizable, we need it on a gnome.org server, than container is probably the most appropriate home: window: 2 gig ram, 72gig (raid 1) disk, load avg ~1 container: 6 gig ram, 500gig (raid 5) disk, load avg ~0.2 Regards, Owen signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: cvs precommit check troubles
I looked a little at getting a newer gettext onto Container, but rebuilding the RHEL4 gettext package for RHEL3 proved to be more work than I wanted to do; and I wasn't that happy with putting custom packages onto container anyways. So, what I did was committed the attached hack to check-po-commit.sh; it simply skips the -c argument to msgfmt for files called 'fa.po'. (Only the Persian team, is to my knowledge, using localized numeric formatters at the current time.) Regards, Owen On Fri, 2005-08-05 at 11:20 -0400, Matthias Clasen wrote: Hi, I can't do a glib release, because gnome cvs won't let me commit glib/po/fa.po, complaining about the I format modifier that is used in there - and that although we do msgfmt -c during distcheck now to verify that all formats are correct! The source of the problem is that the precommit check is run on container, which has a too old gettext to know about the I format modifier. Please update gettext on container to 0.14, or turn off this particular precommit check. Thanks, Matthias PS: I have no idea why this did not happen when I did the earlier 2.7.x releases, which to my knowledge also had the I in fa.po... Index: check-po-commit.sh === RCS file: /cvs/gnome/CVSROOT/check-po-commit.sh,v retrieving revision 1.6 diff -u -p -r1.6 check-po-commit.sh --- check-po-commit.sh 5 Aug 2005 09:59:43 - 1.6 +++ check-po-commit.sh 5 Aug 2005 16:08:25 - @@ -6,9 +6,20 @@ while [ $# -gt 0 ] do +# The Farsi team is using localized numeric formats +# in their .po files, but gettext on cvs.gnome.org isn't +# new enough to handle them. +case $1 in +*fa.po ) + DASH_C= +;; +* ) + DASH_C= -c +;; +esac case $1 in *.po ) -if ! message=`msgfmt -c -o /dev/null $1 21` +if ! message=`msgfmt $DASH_C -o /dev/null $1 21` then cat EOF * signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
