libbonbo - gnome developer libs - string freeze breakage?

2005-02-23 Thread Martin Willemoes Hansen
Hello everybody!

Noticed that two new fuzzy strings in the libbonobo package.

msgid EOF from child process\n

and 

msgid Couldn't spawn a new process

Does this constitute a string freeze breakage?

Happy hacking!
-- 
Martin Willemoes Hansen

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


access keys

2005-02-23 Thread Nikos Charonitakis
hi 
is there any automatic way to check and arrange  access keys in an application?

Nikos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: clock capplet and nautilus date and time formats

2005-02-23 Thread Carlos Perelló Marín
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Nugent wrote:
| Hi Danilo
| yes, I agree the POSIX standard is pretty limited in what you can do
| with it.
|
| The reason I asked the question in the first place is that I was
| thinking of extending the Locale and Culture capplet to wrap glibc
| (currently it does ICU only). However, this doesn't make a lot of sense
| if most of GNOME is not using the OS's date and time formatting. The
| other option would be to extend the capplet further to configure other
| app specific stuff.
|
|
| I had a quick look at KDE and the Country/Region  Language Control
| Center (which looks pretty much like a glibc interface judging by the
| data in it) does provide a mechanism to configure the desktop clock's
| date and time format and the file manager date and time format. I assume
| they implemented some sort of logic in code to knock off seconds  or
| year or whatever when they don't want to display these things.
I found a way to do that creating our own customized locale in user's
home and was planning to implement it with that capplet. The problem is
that it was a long ago and was so stupid I didn't wrote down how to do
it. Will try to find how to do it and will send you it.
KDE just creates its own classes to handle date and time and all
programs should use them to get it. The way I'm talking about gives you
that feature for all applications that use glibc locales.
|
| GNOME's dispersive , inconsistent approach to locale data looks like a
| pretty big defect. Most competing desktops have a consistent approach.
I agree and that was the point I started the capplet.
Cheers.
|
| thx
| Peter
|
|
|
| Danilo egan ha scritto:
|
|Hi Peter,
|
|Today at 12:01, Peter Nugent wrote:
|
|
|
|I've noticed that neither the clock applet or nautilus take their date
|and time formats from the underlying OS eventhough the do take the day
|and month names from it . Is there a reason for this ? and are there any
|plans to change this so that they do ?
|
|
|I'd be strongly opposed to such a change.  We have much bigger control
|of these fields, and locale definitions simply don't provide enough
|options for us.  I.e. for clock applet, we might be interested in the
|following:
|  time with seconds (13:14:15)
|  time without seconds (13:14)
|  date and time, but *without* year (, 14. , 13:14)
|
|while locales (in GNU libc, don't know about other systems) provide
|for me only:
|
|  $ date +%x # d_fmt
|  14.02.2005.
|  $ date +%X # t_fmt
|  13:16:30
|  $ date +%c # d_t_fmt
|  , 14.  2005. 13:16:31 CET
|
|This is simply not enough, and I'd hate to be limited to these options
|(ok, there's also a t_fmt_ampm, but that doesn't apply to my locale).
|
|Also, it's very hard to change locales (I've been trying to do that
|for GNU libc, which is still the base platform for Gnome, for around
|two years, where the sr_YU locale even includes a plus sign in the
|string, which is clearly wrong), while it's much easier to
|administrate translations.
|
|As for Nautilus, it's using a larger granularity (i.e. it again has
|messages for Yesterday, Last Thursday), so above options are
|simply not sufficient.
|
|Yes, in a perfect world we'd have it based on the operating system,
|but we're still far off from perfect world.
|
|
|
|Most apps seems to be doing their own thing regarding the date and time
|formats which leads to an icconsistent end user experience. Other
|desktops have a more cocsistent approach which measn that these things
|can be made configurable through a single app.
|
|
|I think our response has so far been: let translators provide
|consistency instead.  If they feel agree with you, you can ask them
|to use %x, %X and %c wherever strftime formats are asked for,
|but I doubt that will happen.
|
|The step forward might be the Language and Culture capplet (part of
|Gnome Control Center, not installed by default), but I think that the
|major problem is the inscalability of locale system used by systems
|Gnome runs on top of.
|
|
|We might actually go another route: instead of relying on OS, develop
|a library of supported time and date formats (or simply extend
|g_strftime, or whatever it's called, to support special modifiers in
|addition to %x, %X and %c).
|
|Cheers,
|Danilo
|___
|gnome-i18n mailing list
|gnome-i18n@gnome.org
|http://mail.gnome.org/mailman/listinfo/gnome-i18n
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGmNWEuPMamD5V9cRAg8YAJsEFsvE5QthyYVVT3dloWI6HsOAlQCeJc3T
KzOX4xLebfIwkOtb5JXD6OU=
=XoTE
-END PGP SIGNATURE-
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [(RE)ANNOUNCING] nautilus-open-terminal

2005-02-23 Thread Emmanuele Bassi
On Wed, 23 Feb 2005 09:29:35 +0100, Heinrich Rebehn
[EMAIL PROTECTED] wrote:

 NO! Please don't remove yet another valuable feature from GNOME! I use
 Open Terminal from the desktop quite often and would not want to miss
 it! I dont think the feature hurts anyone.

I have an application launcher for gnome-terminal on my lower panel,
and a shortcut to spawn a terminal assigned to the windows key on my
keyboard; I've *never* used the 'Open Terminal' menuitem, though I do
have at least three terminal windows (not counting the tabs) open
during my typical session; and if an Open in terminal menuitem is
added to the directory context menu, the only use of the open
terminal item is really gone.

So, I'd second the idea of removing it - for good - in the next
development cycle.

Regards,
 Emmanuele.

-- 
It is against the grain of modern education to teach children to program.
What fun is there in making plans, acquiring discipline in organizing
thoughts, devoting attention to detail, and learning to be self-critical?
-- Alan Perlis
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: gnome-doc-utils translation guide

2005-02-23 Thread Shaun McCance
On Tue, 2005-02-22 at 10:30 +0100, Danilo egan wrote:
Yesterday at 14:02, Artur Flinta wrote:

 I wonder to know hot to translate messages like:

Look at Translating the Stylesheets chapter of Gnome Documentation
XSLT Manual inside gnome-doc-utils (and other chapters as well). 

For me, it's accessible via Yelp (Gnome Help) in Other Documentation
section. 

Note that the section isn't entirely complete, but it's a really good
start.  I really should put full comments on all the strings, at least
referencing the documentation.  I'm sorry I've been so lax on this. I'll
make a point of completing the translator documentation this weekend,
after I get back home from not-so-sunny California.

--
Shaun


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: libbonobo - gnome developer libs - string freeze breakage?

2005-02-23 Thread Christian Rose
ons 2005-02-23 klockan 11:12 +0100 skrev Martin Willemoes Hansen:
 Hello everybody!
 
 Noticed that two new fuzzy strings in the libbonobo package.
 
 msgid EOF from child process\n
 
 and 
 
 msgid Couldn't spawn a new process
 
 Does this constitute a string freeze breakage?

Yes, it does. Good spotting. Relevant links to the file and the commit
that broke the string freeze seems to be
http://cvs.gnome.org/viewcvs/libbonobo/bonobo-activation/bonobo-activation-fork-server.c?rev=1.23view=log
and
http://cvs.gnome.org/viewcvs/libbonobo/bonobo-activation/bonobo-activation-fork-server.c?r1=1.22r2=1.23
 .

Tor, please revert the two string additions, or, alternatively, provide
an explanation why they need to go in for GNOME 2.10 and cannot wait for
GNOME 2.12, and why you need to break the freeze.
GNOME is currently string frozen, and as libbonobo is part of GNOME
(developer-libs), and libbonobo hasn't branched off yet in a
gnome-2-10 branch, this means that the current freeze still affects
libbonobo HEAD.


Christian

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n