Custom translated fields

[Jaroslaw Staniek]

On 5 July 2015 at 16:00, Albert Astals Cid <aacid at kde.org> wrote:
> El Diumenge, 5 de juliol de 2015, a les 15:39:00, Jaroslaw Staniek va
> escriure:
>> On Sunday, 5 July 2015, Albert Astals Cid <aacid at kde.org> wrote:
>> > El Diumenge, 5 de juliol de 2015, a les 12:19:53, Jaroslaw Staniek va
>> >
>> > escriure:
>> >> Is anyone interested with that?
>> >> Currently I'm editing these desktop files by hand.
>> >
>> > Besides you? I don't think anyone is,
>>
>> That's strong even a bit counterproductive declaration...
>
> What is counterproductive? As far as i know you're the one trying to stretch
> what a .desktop file is and provides, so you're the one with the problem, so i
> guessed you're probably the only one interested in implementing this.
>
>>
>> >we've been using .desktop files for ages
>> >
>> > without the need for translating custom fields.
>>
>> Maybe because this part of the standard isn't implemented and people did
>> not care and add some c++ virtual methods by hand.
>
> Which part of the standard?
>
> The list of fields that a .desktop file reader should support is clearly
> defined at "Recognized desktop entry keys" of
> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html and as far as I can see we translate all those fine.
>

There's a section "Extending the format", KDE uses this possibility a
lot (200+ times in KF5 itself), the implemented probably predates the
actual specs.
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html#extending
KDE people wouldn't use the X- if it was not implemented. So simple.

> Actually i see Icon is missing, we could just as well add it to the hardcoded
> list, but that's a different discussion :)
>
>>
>> > This is for your own app plugins, right? If so why can't you just reuse
>>
>> one of
>>
>> > the existing fields? It is not like anyone else than your will make sense
>>
>> or
>>
>> > even see those .desktop fields, no?
>>
>> It's part of the Plugin api that is intended to be public.
>> Plugins pattern alone is intended for being used for extensibility, by
>> others, right?
>> What translated field can be reused?
>> Name/description are used, keywords will be used, genericname is only left.
>>
>> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
>>
>> I did not mention one thing: the localestring type isn't optional, it's
>> just because the format has no strict validators, nobody bothered I guess.
>
> I can't find in the spec that supporting custom fields of localestring type is
> required by a reader implementation. Actually how can i know that a non-
> standard key is localestring and not numeric? AFAICS I can't.

In the light what I am saying below, we have to note:
- the specs is highly informal (no meaning of must, can, shall is
defined), compare that to ODF...
- using it for plugin descriptions is a little overuse at our side as
you noted too

The specs' language can sound that such that nothing is required.
Reading with a good will is the only thing required I guess :)

So here: neither support for custom boolean nor any custom values is
required. All types are equally described when it comes to importance.

http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html

So the localestring type is not a special one.

>> Hmm as soon as there's a plugin in Kexi (or Krita or other heavy
>> plugin-based app) requiring more than one noun, (provides multiple classes)
>> reusing genericname won't be enough.
>
> Yes, i agree using .desktop to declare strings/features for your plugin is
> probably sub-optimal.
>
> Actually using .desktop files for plugins is already a bit "wrong" since the
> .desktop files spec says they are to describe "how a particular program is to
> be launched, how it appears in menus, etc.".
>
> Maybe we should just use .json which AFAIK (i'm a bit "old") here is what Qt5
> wants for plugins? We have facilities for translating .json too (again not
> really sure how it works).

Yes, deprecating .deskop for plugins (e.g. a warning in
kcoreaddons_desktop_to_json) would be probably the way to go.

>> Disclaimer: It all works for me by editing the files, as I said. I am ok
>> with someone helping out after translation teams back this fix in the fdo
>> implementation.
>
> Editing files by hand can't be considered "works" regarding translations. You
> won't get much coverage since translators won't know they have to go to that
> file to translate it.
>
>> I value most the fact that the task is simple, fixes something missing, and
>> can be delegated easily to some volunteer that would like to start
>> contribution to the core infra.
>
> I disagree that it's either a fix nor simple.

Third option: I can easily generate code for the app that has needed
context and move on.

Please let me know when you retire the desktop files completely for
describing plugins. That would be we especially welcome currently when
we have to cleanup the build subdir in order to get the json generated
properly (https://bugs.kde.org/show_bug.cgi?id=349398).

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek