GNOME Bugzilla – Bug 335720
Untranslatable strings in metacity
Last modified: 2006-04-07 19:06:35 UTC
Hi, I am the coordinator for the GNOME Oriya translation team, and frankly this has been bugging me for a long time. The metacity PO files contain a large number of strings that are overly long, and are poorly written both in terms of clarity and of the usage of English. No offence intended, but they read as if they were written by a non-native English speaker, with little experience in technical writing. This makes the strings almost impossible to translate. There are several such strings, which makes it difficult to list them all here, but a scan of the metacity.pot file should show what I mean. One of the more egregious examples is: #: ../src/metacity.schemas.in.h:19 msgid "" "If true, and the focus mode is either \"sloppy\" or \"mouse\" then the " "focused window will be automatically raised after a delay (the delay is " "specified by the auto_raise_delay key). This preference is poorly named, but " "kept for backwards compatibility. To try to be more clear (at least to the " "technically inclined), its meaning is \"automatically raise the window " "following a timeout which is triggered by non-grabbed mouse entry in sloppy " "or mouse focus modes\". It is unrelated to clicking behavior (i.e. this is " "not related to raise-on-click/orthogonal-raise). It is unrelated to entering " "a window during drag and drop (because that results in the application " "grabbing the mouse)" This reads as if it was written on the fly: It contains too many afterthoughts, the level of detail is too high for the average user, and the second explanation adds little to the clarity. If I was rewriting this, it would read: msgid "" "If set to true, and the focus mode is either \"sloppy\" or \"mouse\" then " "the focused window will be automatically raised after a delay specified by " "the auto_raise_delay key. It is not related to clicking on a window to raise " "it, nor to entering a window during drag-and-drop." I would strongly recommend that a native English speaker. preferrably someone well-versed in technical writing, be asked to look over the strings. If you cannot find such a person, I would be glad to volunteer for the work, except that it will take me maybe a couple of weeks to revise the entire file.
Well, the specific string you mention is my fault. It's not a result of having a different native language; just general incompetence. ;-) You are right that it was written on the fly. Anyway, if you'd like to submit a patch for rewording other parts that would be great. I do not have time for it.
Great. Thank you for being so cooperative. I will submit a patch as soon as I can, but it will take me at least till next week. The question I have is what files do I need to patch? Is just doing metacity.pot enough, or do I have to patch the source files noted in POTFILES.in?
I could try and give a hand if you like. (I'm a native English speaker, fwiw.)
Created attachment 61868 [details] Proposed changes to msgid strings Proposed changes to msgid strings to improve clarity and ease of translation. See writeup in bug report for details.
OK, I went through the .pot file, and the strings that I found difficult to translate were a total of nine, a lot fewer than I had originally thought. Most of the strings come from src/metacity.schemas.in.h, with one from src/theme.c. I am attaching a file of proposed changes for metacity.pot, with a pseudo-diff like structure. Each entry in the file consists of two msgid string, the first being the original from the current HEAD branch, quoted with "> ", and the second being my proposed replacement. If someone (Thomas?) could go through this, and approve the changes, I, or somebody else, could then submit the appropriate patches.
It all looks good to me as a native speaker, but I can't approve it in the sense of saying it should go into metacity.
Oh, there is one more untranslatable string: #. first time through #: ../src/window.c:5407 #, c-format msgid "" "Window %s sets SM_CLIENT_ID on itself, instead of on the WM_CLIENT_LEADER " "window as specified in the ICCCM.\n" This one does not make sense even to a technically-minded person who is not up to details of window managers. Could this be described in simpler words?
Created attachment 62126 [details] [review] Patches to introduce more readable strings, as discussed here. Created patches to make metacity strings more readable, as discussed here.
Comment on attachment 62126 [details] [review] Patches to introduce more readable strings, as discussed here. Sweet, thanks for the work. In the figure, please use the -u option when creating patches (e.g. 'cvs diff -u > name-of-my-wonderful.patch') <snip> >> Many actions (e.g. clicking in the client area, moving or resizing >> the window) normally raise the window as a side-effect. Set this >> option to false to decouple raising from other user >> interactions. When false, windows can still be raised by an >> alt-left-click anywhere on the window or a normal click on the >> window decorations (assuming such clicks aren't used to start a >> move or resize operation). Special messages, such as activation >> requests from pagers, may also raise windows when this option is >> false. This option is currently disabled in click-to-focus mode. It looks like the only change you made here was to convert spaces to tabs. Please don't change any spaces to tabs. (Changing tabs to spaces is okay if there are also other changes on the same line, though we avoid it if there aren't any other changes) <snip> >> If set to true, and the focus mode is either "sloppy" or "mouse" >> then the focused window will be automatically raised after a delay >> specified by the auto_raise_delay key. This is not related to >> clicking on a window to raise it, nor to entering a window during >> drag-and-drop. Looks good. >> titlebars. The size from the description will only be used if the >> titlebar_font_size option is set to 0. Also, this option is disabled >> if the titlebar_uses_desktop_font option is set to true. Oops, looks like we forgot to change this one when we modified the default. Good catch. :) >214,215c201 >< has a fixed maximum (to prevent accidentally destroying >< your desktop by asking for 34 million workspaces). >--- >> has a fixed maximum. This doesn't answer what happens when the user specifies an amount larger than the fixed maximum -- will that cause any probelms for users or will they understand that we just use the fixed maximum (currently 36) when they specify a number that is too large? Looks good otherwise. >< in noisy environments, or when 'audible bell' is off. >--- >> in noisy environments. That's fine. :) >< If true, metacity will give the user less feedback and less >< sense of "direct manipulation", by using wireframes, >< avoiding animations, or other means. This is a significant >< reduction in usability for many users, but may allow legacy >< applications and terminal servers to function when they >< would otherwise be impractical. However, the wireframe >< feature is disabled when accessibility is on to avoid weird >< desktop breakages. >--- >> If true, then Metacity works in terms of applications rather than >> windows. The concept is a bit abstract, but in general an >> application-based setup is more like the Mac and less like >> Windows. When you focus a window in application-based mode, all the >> windows in the application will be raised. Also, in >> application-based mode, focus clicks are not passed through to >> windows in other applications. Application-based mode is, however, >> largely unimplemented at the moment. This change makes absolutely no sense. >977,980c963,966 >< This keybinding changes whether a window is above or below >< other windows. If the window is covered by another window, it raises >< the window above other windows. If the window is already fully visible, >< it lowers the window below other windows. >--- >> This keybinding changes whether a window is above or below other >> windows. If the window is covered by another window, it raises the >> window above all others, and if it is already fully visible, it >> lowers the window below all others. This looks like nothing but spacing changes, right? There's not much point in such changes. <snip> >> Some applications disregard specifications in ways that result in >> window manager misfeatures. This option puts Metacity in a >> rigorously correct mode, which gives a more consistent user >> interface, provided one does not need to run any misbehaving >> applications. I believe there may be good reasons to leave the more verbose version in to explain it, but let's ask Havoc about it. >< _("Coordinate expression parser overflowed its buffer, this is really a Metacity bug, but are you sure you need a huge expression like that?")); >--- >> _("Coordinate expression parser overflowed its buffer.")); Yeah, that's probably fine. >< meta_warning (_("Window %s sets SM_CLIENT_ID on itself, instead of on the WM_CLIENT_LEADER window as specified in the ICCCM.\n"), >--- >> meta_warning (_("Window %s sets the SM_CLIENT_ID property on itself, instead of on the client leader window as specified in the ICCCM.\n"), Why in the world do we have meta_warning strings marked for translation? It just looks like an extra translator burden with no benefit. I'd just say unmark it for translation and otherwise use the original version, but I'd like to ask Havoc as there appears to be quite a number of other strings like this. Havoc: Is there a reason for marking meta_warning strings for translation?
> Sweet, thanks for the work. In the figure, please use the -u option when > creating patches (e.g. 'cvs diff -u > name-of-my-wonderful.patch') OK, so noted. >>> Many actions (e.g. clicking in the client area, moving or resizing >>> the window) [...] > It looks like the only change you made here was to convert spaces to tabs. > Please don't change any spaces to tabs. [...] Oops, sorry. There were supposed to be real changes here. I am not sure what happened. I will submit an updated patch tonight from my home computer, where all the work is. >>< If true, metacity will give the user less feedback and less >>< sense of "direct manipulation", [...] > This change makes absolutely no sense. Something has gone very wrong. This change was supposed to be for a different string. Rather than continue trying to debug this, let me make a fresh patch, and remove the old one tonight. My apologies for wasting your time.
> > This change makes absolutely no sense. > > Something has gone very wrong. This change was supposed to be for a different > string. Rather than continue trying to debug this, let me make a fresh patch, > and remove the old one tonight. My apologies for wasting your time. Not at all; you've spent some time making Metacity better and it didn't take long to read through the various strings. Thanks for working on this. :-)
meta_warning was marked since at some point the message I got was "mark everything" - I think even if it's a "developers-only string" people want to be able to read it in their language and know they don't understand it because it's some obscure ICCCM point, vs. they don't understand it because it's in English ;-) but really, it's up to the translation team.
Re: application_based, that pref should probably just be dropped, no? It's not useful afaik, was really just a mode I was experimenting with that requires pretty pervasive changes throughout gnome to be of interest. A short description is probably fine, I would include words like "experimental" or "don't use this"
Comment on attachment 62126 [details] [review] Patches to introduce more readable strings, as discussed here. Disregard this patch
Created attachment 62477 [details] [review] Fixed patch for more readable strings Fixed patch for more readable, and translatable, strings in metacity.
I have fixed the patch to make metacity strings more readable. I tried to take into account Elijah's comments above. The last remaining quibble there might be is about the change starting: <short>Disable misfeatures that are required by old or broken applications</short> <long> - Some applications break specifications in ways that result - in window manager misfeatures. For example, ideally Metacity I think that it is too verbose. The user does not need to know about all the details that were in the developer's mind when coding, but just how this feature might affect functionality. In any case, please feel free to do whatever edits you deem fit before integrating these changes. (I also used "cvs diff -u" this time. I hope the patch meets your needs.)
Awesome, thanks for all the work. Note that if you have conflict markers (e.g. the <<<<<<< and ====== and >>>>>> in the ChangeLog portion of the patch) in one of your files, you should fix them before trying to make a patch. Also, tabs are evil and shouldn't be added to files other than the ChangeLog and Makefiles. ;-) Anyway, I fixed up things a bit (the ChangeLog, tabs vs. spaces, reverted the window.c change as it's _meant_ to be a for-developers message and users are really unlikely to see it, plus other minor things here and there) and kept the short version as per your reasoning in comment 16. I've committed with those changes; I hope they're all ok but if not, feel free to post a new patch. :-) 2006-03-27 Gora Mohanty <gmohanty@cvs.gnome.org> * src/metacity.schemas.in: * src/theme.c: Changes strings to make them more readable, and more translatable. Fixes #335720.