Custom translated fields

Sun Jul 5 14:00:28 UTC 2015

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.

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.

> 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).

> 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.

Cheers,
  Albert

> Cheers.
> 
> > Cheers,
> > 
> >   Albert
> >> 
> >> On Sunday, 5 July 2015, Albert Astals Cid <aacid at kde.org> wrote:
> >> > El Dilluns, 15 de juny de 2015, a les 22:14:25, Jaroslaw Staniek va
> >> 
> >> escriure:
> >> >> Hi
> >> >> Summing up,
> >> >> 
> >> >> As I need get things done, I'm looking for someone to help me with
> >> >> createdesktopcontext.pl
> >> >> - basically change from
> >> >> 
> >> >>   my $regexp =
> 
> qr{^(Name|Comment|Language|Keywords|X-KDE-Keywords|About|Description|Generi
> 
> >> >> cName|Query|ExtraNames|X-KDE-Submenu)=(.+)};
> >> >> 
> >> >> -- to recognize extra fields of type localestring [1].
> >> > 
> >> > You'll also need to modify applycontext.cpp so that it applies the
> >> 
> >> translation
> >> 
> >> > back to the desktop file.
> >> > 
> >> > Cheers,
> >> > 
> >> >   Albert
> >> >> 
> >> >> Magic "# translate" comment is one solution but another could be that
> >> >> for field Foo I am adding:
> >> >> 
> >> >> Foo=Bar
> >> >> Foo[x-test]=xxBarxx
> >> >> 
> >> >> And in final .desktop file it's rather clean, no extra comments
> 
> appear.
> 
> >> >> [1]
> >> 
> >> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
> >> 
> >> >> On 11 June 2015 at 15:43, Burkhard Lück <lueck at hube-lueck.de> wrote:
> >> >> > Am Donnerstag, 11. Juni 2015, 09:28:40 schrieb Jaroslaw Staniek:
> >> >> >> Thanks, please let me understand; first - regarding
> 
> KPluginMetaData:
> >> >> >> Why is a hint needed there if
> 
> KPluginMetaData::readTranslatedString()
> 
> >> >> >> cust constructs a magic key with a [lang] sufffix?
> >> >> > 
> >> >> > You are right, no hint needed.
> >> >> > 
> >> >> > --
> >> >> > Burkhard Lück