Re: Application names

[William Jon McCann <william jon mccann gmail com>]

Hi,

On Sat, Aug 8, 2009 at 5:34 PM, Frederic Peters<fpeters gnome org> wrote:
> William Jon McCann wrote:
>
>> My proposal for 2.28 is:
>
> UI Freeze for 2.28 is set to Monday; sure we could grant an exception
> and rush things, but I'd prefer to wait for the beginning of 2.29,
> especially as we may want a new translatable key in the desktop files
> and that would give enough time to translators.

We're are not in string freeze yet.  We are free to change any strings
we wish.  Especially since this is mostly removing extra text from
Names - and could even be done by a script in some cases.  So I'm not
sure this alone is a good reason to delay.  We will also have lots of
other things to do in the 2.29 cycle - trust me.  And really 2.28 is
supposed to be a baseline for GNOME Shell testing and we absolutely
need these fixes for that.

> Quoting Vincent Untz and Christian Rose:
>
>  | >  And do you think the burden of adding a new translatable key to all
>  | >  desktop files would be okay for translator teams?
>  | Yes, if the changes/patches are done in time in the beginning of a new
>  | release cycle, I think it will be acceptable by most translators.
>
>  -- http://mail.gnome.org/archives/gnome-i18n/2009-August/msg00063.html
>
> David Faure (of KDE fame) was away until August 4th, and didn't speak
> since he's been back, but wrote before going on vacations:
>
>  | But if the one who adds FullName to every desktop file also fixes up the
>  | Name and GenericName keys of the file in order to stop the duplication
>  | nonsense there and actually follow the spec then I guess I withdraw my
>  | objection against FullName.
>
>  -- http://lists.freedesktop.org/archives/xdg/2009-July/010816.html
>
> Let's engage him back into the discussion, which has now been
> clarified with regards to two important points:
>
>  * it's not a matter of avoiding fixing GNOME desktop files
>  * a new key is required for pleasant translations

Feel free to do that.  However, it should not hold up fixing the panel
and desktop files.  As I pointed out in the blog, we have to do this
even if we add FullName to the spec.  FullName would be yet another
way applications could be shown - and why I don't think it is a good
idea anymore.

> And I hope we can then reach an agreement.  (yes I read your blog
> post, and you may not believe an agreement is possible, I think
> it is too early to give up).
>
> However for compatibility reasons, I have been interested by Colin
> Walters comments:
>
>  | If we change the Name field now, concretely it will be a huge pain for
>  | application writers because if their app is used on older GNOME
>  | releases it will fail.

Last I talked to Colin he was satisfied after he updated my patch in
bugzilla for the panel.  I think he was overstating the problem a bit
though.  The point is we have to fix the names for the shell, for KDE
compatibility, and to honor the spec.  Any apps that honored the spec
will be fine, and any apps that followed our unwise advice to make
Name use Name+GenericName are fixed by Colin's latest patch.

...
> Going back to your proposed guidelines:
>
>  | When Name is the same as GenericName, the GenericName should be removed
>
> Definitely agree.
>
>  | The desktop entry Name value, application menu (for GNOME shell),
>  | window titlebar (for GNOME 2.x), documentation, and about dialog
>  | should all use the same name
>
> Mmmm. See below.
>
>  | The desktop entry Name value should be the brand name unless the
>  | application is a simple (single purpose), core GNOME built-in and does
>  | not have an established external brand identity (web site, online help,
>  | etc)
>  |
>  | Brand names should be considered carefully but can’t be relied on to
>  | indicate functionality in many languages
>
> As noted by mpt during GCDS, we have a lot of sucky brandnames; as the
> Name key will be exposed in many places that are not out of GNOME realm,
> I believe it is nice to keep it somehow understandable (Agave Color
> Picker instead of Agave).

One of the reasons why we are seeing crappy names is that we are
masking the problem.  We should provide aliases for bad names.
Application authors pick bad names they get what they get.  If we
picked bad names - we should change them.

>
> Anyway my summary would be to have the discussion now, but the changes
> in 2.29, with an enhancement to the spec if possible.

We still have time before string freeze, we'll have our hands full
with other issues during 2.29, and we want 2.28 to be a viable testing
platform for the Shell.  Let's do it now.

Thanks,
Jon