Description of problem: The menuitem for system-config-date isn't localized to german. On my Xfce the item is named "System-Config-Date" Version-Release number of selected component (if applicable): system-config-date-1.9.66-1.fc16.noarch How reproducible: allways Steps to Reproduce: 1. On Xfce press the menu-button 2. Navigate to the administration submenu Actual results: The menuitem for system-config-date is named "System-Config-Date" Expected results: The menuitem should be named something like "Datum und Uhrzeit" Additional info:
This is because XFCE seems to only use the Name property of the application desktop file, and "System-Config-Date" is the name of the program. To get a localized description, it could e.g. display the GenericName ("Set Date & Time" -> "Datum und Zeit einstellen") alongside Name. Or use the fallback I put in for GNOME (sigh), X-GNOME-FullName ("System-Config-Date (Set Date & Time)" -> "System-Config-Date (Datum und Zeit einstellen)"). Changing component to xfce4-panel, I guess this could be the right component for this in XFCE (if not, please dispatch further).
There is nothing that Xfce could do here: Name=System-Config-Date Name[bg]=System-Config-Date Name[da]=System-Config-Date Name[de]=System-Config-Date Name[es]=Configuración de fecha del sistema Name[et]=System-Config-Date Name[fi]=System-Config-Date Name[fr]=System-Config-Date Name[hu]=System-Config-Date Name[it]=System-Config-Date Name[ja]=system-config-date Name[nl]=System-Config-Date Name[pl]=system-config-date Name[pt]=System-Config-Date Name[pt_BR]=System-Config-Date Name[sv]=System-Config-Date Name[uk]=System-Config-Date Name[zh_CN]=System-Config-Date Name[zh_TW]=System-Config-Date You can change the menu to use GenericName, but this will also affect other applications. There is no rule in the XDG menu entry spec that 'Name' needs to match 'Exec'. IHMO the bug is in system-config-date. Take a look at the other system-config-* tools: grep -e ^Name[[]de[]] /usr/share/applications/system-config-* /usr/share/applications/system-config-date.desktop:Name[de]=System-Config-Date /usr/share/applications/system-config-firewall.desktop:Name[de]=Firewall /usr/share/applications/system-config-keyboard.desktop:Name[de]=Tastatur /usr/share/applications/system-config-kickstart.desktop:Name[de]=Kickstart /usr/share/applications/system-config-language.desktop:Name[de]=Sprache /usr/share/applications/system-config-printer.desktop:Name[de]=Drucken /usr/share/applications/system-config-samba.desktop:Name[de]=Samba /usr/share/applications/system-config-services.desktop:Name[de]=Dienste /usr/share/applications/system-config-users.desktop:Name[de]=Benutzer und Gruppen One of these things is not like the others. Remember Sesame Street? ;)
You're alluding to the practice of putting the generic (as opposed to the specific) name into "Name" as a workaround for GNOME. However, the desktop entry spec is quite explicit[1] that "Name" is meant to be specific (e.g. "Mozilla") instead of generic ("Web Browser"). It seems this issue finally caught someone's eye at GNOME as well[2]. While s-c-date long used the workaround, I reverted to complying with the standard because using the generic name conflicted with the GNOME date and time settings tool[3]. Over time I'll change that for my other config tools as well (can't speak for other maintainers). I realize this is not a pretty situation for DEs, because one application uses the old way and another the new one, but this will not be solved if applications just kept on using the old, broken scheme indefinitely. [1]: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html [2]: https://live.gnome.org/GnomeGoals/CorrectDesktopFiles [3]: https://bugzilla.redhat.com/show_bug.cgi?id=727204
(In reply to comment #3) > You're alluding to the practice of putting the generic (as opposed to the > specific) name into "Name" as a workaround for GNOME. However, the desktop > entry spec is quite explicit[1] that "Name" is meant to be specific (e.g. > "Mozilla") instead of generic ("Web Browser"). I fully agree, but the spec also states that "Name" is not the same as "Exec". Usually the *name* of an application is not the command you need to run it but the title of a window, for example "Mozilla Firefox" rather than "firefox" (and rather than "Webbrowser"). "System-Config-Date" is neither one nor the other, neither fish nor fowl. The window title is 'Time/Date properties'. If it was "System-Config-Date", how would you localize that? The characteristic of a real *name* is that everybody knows the application by its name, thus there is no need to translate it. In fact it should not be translated: I doubt anybody here in Germany knows the browsers "Rotfuchs" or "Offenbarung". > It seems this issue finally caught someone's eye at GNOME as well[2]. This is a different issue. This is about mixing Name and GenericName or more precisely about duplicating info by adding GenericName to Name. This proposal does not say one must not use generic terms as Name. It only says that GenericName should be removed if it matches Name. > While s-c-date long used the workaround, I reverted to complying with the > standard because using the generic name conflicted with the GNOME date and time > settings tool[3]. That is a problem with GNOME: GNOME no longer distinguishes categories and doesn't display tooltips either. There are tons of but reports out there, so obviously GNOME's behaviour is not user-friendly. Please don't make it a problem for all desktops. Our system-config-* tools should remain generic. > Over time I'll change that for my other config tools as well > (can't speak for other maintainers). I realize this is not a pretty situation > for DEs, because one application uses the old way and another the new one, but > this will not be solved if applications just kept on using the old, broken > scheme indefinitely. I agree the current situation is suboptimal because developers are mixing Name and GenericName. But I strongly object that you introduce a workaround for GNOME the expense of other desktops. If you really think the bug is in xfce4-panel, please clone this bug for kdebase-workspace, lxpanel and other desktop environments/window managers that are affected by your change to give their maintainers a chance to state their opinion. > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=727204 The reporter suggested to hide the apps that are superseded by a GNOME equivalent. Have you ever thought about this?
Nils, your thoughts please.
Sorry, got distracted... I think we were talking a bit cross purposes here, however. In comment #1, I probably should have said that "System-Config-Date" is the name, and that it's up to the DE to render Name (which isn't localized) and/or GenericName (which is) in its menus, and that I'll pass this on for further triaging. (In reply to comment #4) > (In reply to comment #3) > > You're alluding to the practice of putting the generic (as opposed to the > > specific) name into "Name" as a workaround for GNOME. However, the desktop > > entry spec is quite explicit[1] that "Name" is meant to be specific (e.g. > > "Mozilla") instead of generic ("Web Browser"). > > I fully agree, but the spec also states that "Name" is not the same as "Exec". > Usually the *name* of an application is not the command you need to run it but > the title of a window, for example "Mozilla Firefox" rather than "firefox" (and > rather than "Webbrowser"). > > "System-Config-Date" is neither one nor the other, neither fish nor fowl. The > window title is 'Time/Date properties'. If it was "System-Config-Date", how > would you localize that? > > The characteristic of a real *name* is that everybody knows the application by > its name, thus there is no need to translate it. In fact it should not be > translated: I doubt anybody here in Germany knows the browsers "Rotfuchs" or > "Offenbarung". I dispute that a name would have to be known by everyone before it'd be considered as such. For want of better alternatives, "System-Config-Date" is its name -- not a pretty or ideal one, admittedly (and I'm open for suggestions, but it won't be "Time and Date Properties Tool" or a similar abomination ;-)). Point taken for the window title, I'll fix this. > > While s-c-date long used the workaround, I reverted to complying with the > > standard because using the generic name conflicted with the GNOME date and time > > settings tool[3]. > > That is a problem with GNOME: GNOME no longer distinguishes categories and > doesn't display tooltips either. There are tons of but reports out there, so > obviously GNOME's behaviour is not user-friendly. > > Please don't make it a problem for all desktops. Our system-config-* tools > should remain generic. I didn't want to cause you problems -- it's your decision e.g. to say "we'll only display the name of the application, not the generic name" which would lead to only "System-Config-Date" being in the menus, case closed, not a bug. > > Over time I'll change that for my other config tools as well > > (can't speak for other maintainers). I realize this is not a pretty situation > > for DEs, because one application uses the old way and another the new one, but > > this will not be solved if applications just kept on using the old, broken > > scheme indefinitely. > > I agree the current situation is suboptimal because developers are mixing Name > and GenericName. But I strongly object that you introduce a workaround for > GNOME the expense of other desktops. This wasn't my intention -- the only thing catering to GNOME specifically is the added X-GNOME-FullName tag, which you can simply ignore. > If you really think the bug is in xfce4-panel, please clone this bug for > kdebase-workspace, lxpanel and other desktop environments/window managers that > are affected by your change to give their maintainers a chance to state their > opinion. > > > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=727204 As above: not really, I'm okay if XFCE only displays the name, and if that is > The reporter suggested to hide the apps that are superseded by a GNOME > equivalent. Have you ever thought about this? A bit, but if somebody bothered to install it, they surely want to use it as well. TL;DR: if you say that only displaying the name in XFCE menus is how you want to do it, fine by me and sorry for the hassle :-).
(In reply to comment #6) > I dispute that a name would have to be known by everyone before it'd be > considered as such. What is the worth of a name then? If you were not known as Nils, why would you have a name at all? What purpose would it serve? If people wouldn't know you name, they would probably use a description like "The guy with the dark/blonde/long/short/whatever hair". Same with s-c-d: If you dispute that the name System-Config-Date is known, then it's in fact one more reason to use a descriptive name. :) > For want of better alternatives, "System-Config-Date" is > its name -- not a pretty or ideal one, admittedly (and I'm open for > suggestions, but it won't be "Time and Date Properties Tool" or a similar > abomination ;-)). Do you really think that all our users know "System-Config-Date", even people who don't speak English? You think that people would type this in the search field of the GNOME shell? I agree that "Time and Date Properties Tool" doesn't sound catchy, but at least it can be translated and people have a chance of finding it. Why not "Time and Date Properties" or simply "Time and Date"? Oh, right, GNOME shell cannot cope with it. But again: Instead of making this a problem of all desktops (including GNOME fallback), better fix this in your application or the shell. Why not just add Don'tShowIn=GNOME;? This tool is obsolete in GNOME anyway. > Point taken for the window title, I'll fix this. Please don't, I think this is a fix for the worse and we should rather discuss this in a broader audience first. > I didn't want to cause you problems -- it's your decision e.g. to say "we'll > only display the name of the application, not the generic name" which would > lead to only "System-Config-Date" being in the menus, It's not my decision, it's a configuration option (at least in Xfce and KDE), so it's the user's decision. > case closed, not a bug. Obviously not. That fact that somebody filed this bug shows that there *is* a problem with system-config-date. > This wasn't my intention -- the only thing catering to GNOME specifically is > the added X-GNOME-FullName tag, which you can simply ignore. But this basically means that the only proper name is a field that is not freedesktop compliant. > As above: not really, I'm okay if XFCE only displays the name, and if that is I'm sorry, but what does "not really" mean in this context? Are you saying you don't want to clone the bugs in order to discuss it with the maintainers affected? > TL;DR: if you say that only displaying the name in XFCE menus is how you want > to do it, fine by me and sorry for the hassle :-). What I wanted to say is: 1. I am not to decide what is displayed, the user is. Both Xfce and KDE are just using the name as default. 2. I want a name that is either a real name (and not a description) or a descriptive name. But if it's descriptive, it should be localized. 3. This bug was filed against system-config-date. Please don't reassign it to a random component again. This is not specific to xfce4-panel but affects many more. 4. If you want to reassign this bug, please clone it properly for *all* affected components (kdebase-workspace, gnome-panel, xfce4-panel, lxpanel, fbpanel, openbox, just to name a few) I hope you got my point, if not, I really don't know how else I should explain it.
Uhh, I see the menu item in F16 is now "System-Config-Date (Set Date & Time)". This doesn't even go with the GNOME guidelines.
Sorry, but how many time do want to additionaly waste for such a small chane? I'm running Fedora 17 beta and this is still not fixed. That's a shame! But maybe you get it fixed in Fedora 18 or later m(
Sorry for dropping the ball on this (at least Bugzilla-wise). IIRC, Christoph and I talked a little about this at the Brno devconf this year, but I forgot about it afterwards :-(. Anyway, my thoughts: Renaming something is not a "small change". The issue besides that the various DEs adhere to standards, uhm, differently :-) is that s-c-date never had a spiffy name like other tools, but that isn't very relevant at all I think: the (human-readable) name of the tool is "System-Config-Date", the Unix-ish name (used for tarballs etc.) and command line is "system-config-date", and it sets date and time. All that is encoded in the desktop file, both separately and combined (regrettably via a non-standard tag), untranslated in the case of the name itself, the rest is translated. I personally think that its name should show up in menus etc. so as to be distinguishable from other tools doing the same or similar things. Christoph, if there's any category or tag that is needed for XFCE to handle it in a special way (e.g. to sort it into settings rather besides normal applications), let me know. I'm positive that there's not much else I can do about it, except rebranding the whole thing and that'd be entirely too much trouble. I would have to come up with a spiffy name for starters ;-).
(In reply to comment #10) > Sorry for dropping the ball on this (at least Bugzilla-wise). IIRC, > Christoph and I talked a little about this at the Brno devconf this year, > but I forgot about it afterwards :-( No problem, I dropped the ball, too, we are both just too busy I guess. > Renaming something is not a "small change". Is it really a big deal? How did you do it last time then? I mean, I don't see a bug report or recall a public discussion. > The issue besides that the > various DEs adhere to standards, uhm, differently :-) Fact: In this case all of KDE, Xfce, LXDE, Mate, Cinnamon, Sugar, Openbox, Fluxbox and many others behave correctly. Only GNOME does not. > the (human-readable) name of the tool is "System-Config-Date", the > Unix-ish name (used for tarballs etc.) and command line is > "system-config-date", and it sets date and time. Well, gnome-default-application-properties sets the default applications in GNOME, nevertheless that's not how it's called in the menu - for a good reason. > All that is encoded in the desktop file, both separately and combined > (regrettably via a non-standard tag), untranslated in the case of the name > itself, the rest is translated. I personally think that its name should show > up in menus etc. so as to be distinguishable from other tools doing the same > or similar things. Personally I don't think the name matters. It's a configuration dialog but not an application. While people have strong feelings to prefer Firefox over Chrome or vim over emacs or vice versa, for a configuration dialog that doesn't really matter. One shouldn't even have two installed. But I do agree it should be distinguishable. Usually this is done via categories, "Adminstration" vs. "Preferences", global vs. personal settings. But GNOME doesn't support this. :( In this case it usually comes down to Name and description, e.g. Name=Firefox web browser GenericName=Web browser Description=Browse the web with Mozilla Firefox This is what GNOME has done in the past and here in Germany, we had an agreement between the translators of GNOME, Xfce and LXDE to do it this way. Unforatunately GNOME has decided to change that, too in 3.0, so now the GNOME core components just use the program name while most others still use name + description. > Christoph, if there's any category or tag that is needed for XFCE to handle > it in a special way (e.g. to sort it into settings rather besides normal > applications), let me know. The categories are fine. "System;Settings;" makes apps show up under Administration, "Settings;" (without System) will make it show up under Preferences. Xfce still has a couple of private X-XFCE-* categories, e.g X-XFCE-HardwareSettings, but they should only be used for settings dialogs which can be embedded into xfce4-settings-manager (and are then marked with X-XFCE-SettingsDialog). Anyway, there is nothing we need to change for Xfce and nothing that would help us with the other desktops. > I'm positive that there's not much else I can do > about it, except rebranding the whole thing and that'd be entirely too much > trouble. Again, this makes me wonder why renaming it to system-config-date was so easy but renaming it back should be so hard.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening, we dropped the ball again. Will you be at devconf to discuss this?
The issue still exits in Mate f18 too, i expected a german localization.
(In reply to comment #14) > Reopening, we dropped the ball again. Will you be at devconf to discuss this? I'll be at the devconf, I expect to arrive on Friday evening. Let me just rehash my point of view as a starting point, so that we won't have another "we discussed something on devconf but don't know what exactly" :-), and also for those who won't be there: The program always had a name based on "date" (or "time") and "config": "dateconfig", was deemed "too generic, descriptive" -> "redhat-config-date", need to get rid of "redhat" due to trademark concerns -> "system-config-date" (also "timeconfig" at some point but I try to ignore that). Yes, the name is not spiffy or something and awfully generic to boot. I'm not sure the tool needs a spiffy name however (it's too small IMO). For a long time the desktop file didn't have the name but the description in the "Name" entry. IIRC, this was because the GNOME project, who came up with the desktop file standard to a large part and used it first, didn't adhere to it themselves: they didn't use the GenericName entry when it was standardized (which is also a bit misleading, it's not a name but something like a functional description) but insisted on either only having the functional description in the name, or name plus functional description. Works if you only cater for GNOME, not so much with other DEs, or programs that have similar functionality to a component included in the desktops (which we have here). A bug was opened against s-c-date (bug #727204) that its menu entry conflicted with the similar GNOME component, therefore I changed the desktop file to adhere to the documented standard: Name holds the name ("System-Config-Date", untranslated), GenericName the functional description ("Set Date & Time", translated) and the non-standardized X-GNOME-FullName which has name plus functional description rolled into one (again because of GNOME). The alternative would have been to remove it from GNOME menus completely which is nonsensical because it isn't installed per default -- and if a user installs it they probably also want to find it in the menus (and I don't want bugreports if they don't). Again, I'm sorry for not giving the other desktops a heads up and only tested in GNOME and KDE -- but that's water under the bridge.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.