GNOME Bugzilla – Bug 112527
Some random string fixes
Last modified: 2004-12-22 21:47:04 UTC
Hi there! Patch incoming... regs, Chris
Created attachment 16345 [details] [review] I'm a patch.
These are my changes: gnome-panel/gnome-panel-screenshot.c: s/room/disk space/ gnome-panel/gnome-panel-screenshot.glade: s/public__html/public_html/ gnome-panel/launcher.c: Assimilated two very similar strings. gnome-panel/menu.c: We are a multi-user system. s/your computer/the computer/; Assimilated two strings gnome-panel/panel-bindings.c: s/gconf/GConf/ gnome-panel/panel-general.schemas.in: Make short description even shorter. panel-global.schemas.in: s/screen shot/screenshot/ gnome-panel/panel.c: Made panel deletion warning a bit prettier, assimilated two strings. applets/wncklet/window-list.schemas.in: s/bring window/move window/ - consistency with metacity; Shorten some descriptions (just the obsolete part, we don't habe different panel types anymore). Changing some bug data. regs, Chris
I'm no maintainer (I'm just on the bugsquad), but I have a few comments that others can feel free to follow or ignore: In regards to: - _("Not enough room to write file %s"), + _("Not enough disk space to write file %s"), I don't have a problem with the original, but if you want to change to the second, I believe you'd need the word free in there (i.e. s/disk space/free disk space/). I doubt an 80 Gig hard drive wouldn't have enough disk space, though there might not be enough of it that is still unused. Perhaps I'm being picky, but this is the way it struck me when I first read it and I'm afraid it might come across to others the same way. In regards to: - "and its\n settings are lost. " + "and it's settings are lost.\n\n" I believe that its is correct, not it's. In regards to: - _("Cannot launch icon\n%s"), - error->message); + _("<b>Cannot launch icon</b>\n\n" + "Details: %s"), error->message); I've read bug reports where members of the translation team said that markup tags should not be part of strings. Doing so made translation more difficult and it's fairly simple to put those tags elsewhere. In regards to the you/your vs. the: I sort of like you/your better. Granted, each computer may have multiple users. However, there is generally more than one computer around as well (which makes "the computer" make less sense). Even if you are sharing one of the computers with other people, the fact that you are using it in a sense allows you to refer to it as "your computer". I don't mean to nit-pick; I think several of the changes are good and/or necessary. It's just that I also see several changes as potentially problematic, with other changes as being somewhere in between. I'm removing the easy-fix keyword (I believe that is used for bugs where a fix hasn't been found and it should be easy to provide a patch for--but we already have a patch). I'm also adding the GNOMEVER2.3 keyword. I'm wondering if the usability team should be cc'ed--anyone have thoughts on that?
Christian: thanks for the patch - looks mostly good. Elijah does point out some things that need to be fixed. Please fix them up and commit. Thanks.
Thanks for your fast response and nice suggestions! The first two issues are already fixed in my local tree, for the other ones: > - _("Cannot launch icon\n%s"), > - error->message); > + _("<b>Cannot launch icon</b>\n\n" > + "Details: %s"), error->message); > I've read bug reports where members of the translation team said that > markup tags should not be part of strings. Doing so made translation > more difficult and it's fairly simple to put those tags elsewhere. I think in this case it's good to have the whole context as this long strings allows translators to change the number of newlines between the two string components. Maybe this is relevant for some non-western languages with different glyphs. But of course we can do some string magic, if you insist on it. > In regards to the you/your vs. the: I sort of like you/your better. > Granted, each computer may have multiple users. However, there is > generally more than one computer around as well (which makes "the > computer" make less sense). Even if you are sharing one of the > computers with other people, the fact that you are using it in a sense > allows you to refer to it as "your computer". This is your personal opinion, I'm not sure whether that's a good idea. Maybe we should consult the usability team. regs, Chris
Adding usability list to CC. regs, Chris
One quick follow-up: As to the you/your vs. the: Yes, it was my opinion. I have no idea whether the usability team would prefer my way or would tell me I was full of crap. I wouldn't be surprised if it was the latter (I'm no usability expert either). I'm sort of surprised Mark didn't comment on this specifically. Anyway, I think it was a good idea to cc the usability team about this one. As to the - _("Cannot launch icon\n%s"), - error->message); + _("<b>Cannot launch icon</b>\n\n" + "Details: %s"), error->message); change: I think your change of moving the newlines makes sense (although I wonder if the translation team would like those outside the string, for the same reason as the <b> and </b> markup tags), I was just commenting that I remember translators not liking the markup tags in the strings. Since we've cc'ed the usability team about you/your vs. the, I'm adding the usability keyword. Since we're talking about translation issues (and I really don't know anything other than "I've read some bug reports that say..."), I'm adding the I18N keyword and cc'ing Christian Rose. (Christian: I didn't know the address I should cc. If I shouldn't cc you directly, let me know the address I should use.)
> - _("Cannot launch icon\n%s"), > - error->message); > + _("<b>Cannot launch icon</b>\n\n" > + "Details: %s"), error->message); > > change: I think your change of moving the newlines makes sense > (although I wonder if the translation team would like those outside > the string, for the same reason as the <b> and </b> markup tags), I > was just commenting that I remember translators not liking the > markup tags in the strings. This is entirely correct. The details can be found at http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#avoid-markup. Use of markup like this inside messages marked for translation should be avoided. In this case the message could preferrably be split into "Cannot launch icon" and "Details: %s", for example. The argument presented in the bug report for keeping this as one message with markup included seems to be for context reasons, but I don't see how the context is needed in this case, nor do I think that we should include extra context and make messages require more work in general, unless we are absolutely sure the extra context is needed. Keeping an entire paragraph of text together in a single message for context reasons is understandable and probably advisable where such paragraphs exist, but in this case the message is already divided into separate paragraphs by newlines, which probably also points out that there's already very little necessary context shared. The advise about paragraph-sized messages at most can be found at http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#long-messages. > Since we're talking about translation issues (and I really don't > know anything other than "I've read some bug reports that say..."), > I'm adding the I18N keyword and cc'ing Christian Rose. (Christian: > I didn't know the address I should cc. If I shouldn't cc you > directly, let me know the address I should use.) Yes, cc:ing me this way is perfectly fine. Thanks.
Eugene or Pat would be best to ask about the your/the issue.
I sat down today and hacked to remove the pango from gettextized strings - I succeded :) Could sb. please state clear on the your/the issue? regs, Chris
In general direct speech is acceptable, so a phrase such as the following is style guide compliant: "Lock the screen so you can temporarily leave your computer" Having said that, why do you need to say anything more than "Lock the screen"? Same applies to "Find folders, files or documents". Pat
I spotted something in the patch for panel.c. Can we change the following: _("When a panel is deleted, the panel " + "and it's settings are lost.\n\n" to When you delete a panel, the settings for the panel are also deleted.
Pat: Shouldn't a tooltip give a verbose description? Eugene: OK, I'll change it. I'm just not sure whether it's a good idea to imply that the user owns the computer he's working on - especially when considering that we talk about admins and user rights in GDM and some other apps. regs, Chris
Created attachment 16742 [details] [review] New schemas patch. Various cool unification string changes.
I'm splitting the patch as e.g. translators should profit instantly from the schemas changes. regs, Chris
Created attachment 16771 [details] [review] New version of schemas patch. Even shortened some short descriptions, many, many slight fixes.
Chris: many of these changes seem to be re-formatting changes: - <long>The user's directory in which screenshots should be - saved so as to appear on the web.</long> + <long> + The user's directory in which screenshots should be + saved so as to appear on the web. + </long> This is wrong: - toplevel panel. The settings for each of these panels is + toplevel panel. The setttings for each of these panels are I don't see much point in things like this: - <short>FIXME - need to define limits</short> + <short>FIXME - need to define limits.</short> (I'd much prefer the FIXME to be fixed) But there is lots of good stuff in there that I'd like to get into CVS. But all these random changes make it harder to review the good changes ... could you go through your patch and remove all the random stuff? Thanks ...
Heh, they're not that random :). I felt that we need a consistent way of formatting strings,so all strings (long, short) now have a trailing full-stop (aka "."). Another criteria was schema structure consistency which meant re-aligning / trashing of tabs. I know, such changes are purely cosmetic and in some way show my finickiness when it comes to subjective code quality impressions, but as you may know diligence is a must. Thanks for pointing out that horrible typo. These changes follow a clear paradigm (unification, simpliticity), so I'm not willing to throw away some of them - as some keys have been fixed in many aspects I would have to separate them out in a way that would require more work than reviewing my "random" changes does. regs, Chris
One thing that would be nice to consider would be formatting the messages such that the number of trailing newlines (\n) are reduced in the messages.
Christian: In my local tree I've eleminated all trailing "\n"s in gettext tags by adding some smart g_strconcat calls :). I just want to review/commit all those fixes step-by-step. regs, Chris
Created attachment 16798 [details] [review] 2nd schemas patch (against applets subdir)
>>Pat: Shouldn't a tooltip give a verbose description? Only if the description provides extra useful information. A tooltip such as "Lock the screen so you can leave your computer" adds no extra information. "Lock the screen" is ample. Pat
Mark: I'm very disappointed. Nobody was willing to review THIS patch but #113433 has been commited, which is not very clean and conflicts in almost every single place with my patch. In addition, it's far away from touching each pango marked-up string in gnome-panel. Of course, you can blame me for not explicitly announcing that my 2nd patch modifies markup, too - but I'm just disappointed because I announced heavy string changes and another string patch has been commited without reviewing this schemas patch. Just a few lines, a few words like "please submit the code patch, too - I don't want to review your schemas patch" would have been enough. It's just frustrating when you have to throw away code you needed hours for. regs, Chris
Added dependency on other string bug. regs, Chris
Christian: the reason I haven't back got to this patch is that you've made if very difficult for me to review this and commit it quickly. I don't have time to spend a long time looking at this. I started going through the patch again just, but was frustrated after the first few changes. Please do the following: * Remove all formatting only changes. For example, this change: - <short>The fish's name</short> - <long> A fish without a name is a pretty dull fish. Bring your fish to life by naming him.</long> + <short>Fish's name.</short> + <long> + A fish without a name is a pretty dull fish. Bring your fish to + life by naming him. + </long> should not change the <long> line. Changing it means I have to read it to figure out what you changed. Just changing formatting is a waste of time. Also, delete changes like: - <schemalist> + <schemalist> * Please don't add a period to short descriptions. See bug #114590. * The default hour format for en_US in clock.schemas shouldn't be deleted. Its not worth creating an en_US translation for it. Thanks for working on this.
Created attachment 18100 [details] [review] Updated 1st patch against HEAD. Resolved some conflicts.
>* Remove all formatting only changes. Maybe this makes it hard for you to see all the string changes. But here a trick from an experienced translator: cd into the po subdir, do intltool-update -p, move the file gnome-panel-2.0.pot to <someotherfilename>, apply the patch, do another intltool-update -p and compare <someotherfilename> and gnome-panel-2.0.pot to see what changed string-wise. >Just changing formatting is a waste of time. I totally disagree with you. Correct formatting means clean code. We want clean code in core packages, don't we? >* Please don't add a period to short descriptions. See bug #114590. Fixed in newest version of first patch. New second patch will follow. >* The default hour format for en_US in clock.schemas shouldn't be deleted. Its not worth creating an en_US translation for it. Sorry, but putting translations into data files is nothing more than a weird hack. Separating it out may look like overhead to you but we have to stick to clean implementations, especially when it comes to formal thingies. Christian: What do you think about the ĺatter i18n issue? regs, Chris
Thanks for doing as I asked Christian - that patch was much easier to review. I've comitte it to HEAD: 2003-07-07 Mark McLoughlin <mark@skynet.ie> * gnome-panel-screenshot.schemas.in: * panel-general.schemas.in: * panel-global.schemas.in: * panel-object.schemas.in: * panel-toplevel.schemas.in: much work on keys documentation to make it more consitent, fix typos and use correct terminology. Patch from Christian Neumair in bug #112527.
Mark: Thanks for the quick commit. Regarding the en_US issue: What do you think of simply making the default value 12? We use many US defaults in other places if the locale doesn't specify any override value. Why did you resolve the bug? It still contains another round of schema fixes and some C fixes. regs, Chris
Manny: to be honest with you, I've lost track of what this bug is about. Starting with new individual bug for any remaining issues sounds like a good idea and titling it with a description of the bug rather than "Some random string fixes". What, I mean by that is if you have a patch to stop "\n"s from being translated, log a bug with the title "newlines should not be marked for translation" and add your patch there. That way its easier to review the patch (because the patch addresses only a single issue) and the discussion is easy to follow because its only about a single issue. As for the en_US translation for the clock, if you want to change the way thats done re-open bug #87872 with your suggestion for how to do it and what you feel is wrong with the current way. Personally, though, I don't see a problem with the way its currently done.