Re: Custom translated fields
On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 10 de juny de 2015, a les 13:24:57, Jaroslaw Staniek va escriure: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view =markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. How does this work for languages with multiple plurals? For the need I presented it's out of scope. The 'tables' here refers to a set, just that. Cheers, Albert It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
El Diumenge, 5 de juliol de 2015, a les 08:48:20, Jaroslaw Staniek va escriure: On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 10 de juny de 2015, a les 13:24:57, Jaroslaw Staniek va escriure: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view =markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. How does this work for languages with multiple plurals? For the need I presented it's out of scope. The 'tables' here refers to a set, just that. Why do you need this to be part of the .desktop file instead of being somethign your plugin api provides, is it because you don't want to load the plugin to access it? Cheers, Albert Cheers, Albert It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On Sunday, 5 July 2015, Albert Astals Cid aa...@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...
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.
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.
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.
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.
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.
Cheers.
Cheers,
Albert
On Sunday, 5 July 2015, Albert Astals Cid aa...@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 lu...@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
--
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
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
Exactly, Albert. On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 5 de juliol de 2015, a les 08:48:20, Jaroslaw Staniek va escriure: On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 10 de juny de 2015, a les 13:24:57, Jaroslaw Staniek va escriure: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view =markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. How does this work for languages with multiple plurals? For the need I presented it's out of scope. The 'tables' here refers to a set, just that. Why do you need this to be part of the .desktop file instead of being somethign your plugin api provides, is it because you don't want to load the plugin to access it? Cheers, Albert Cheers, Albert It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
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, we've been using .desktop files for ages
without the need for translating custom fields.
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?
Cheers,
Albert
On Sunday, 5 July 2015, Albert Astals Cid aa...@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 lu...@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
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
El Diumenge, 5 de juliol de 2015, a les 15:39:00, Jaroslaw Staniek va
escriure:
On Sunday, 5 July 2015, Albert Astals Cid aa...@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 aa...@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 lu...@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
___
Kde-frameworks-devel mailing list
Re: Custom translated fields
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 lu...@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
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On 5 July 2015 at 16:00, Albert Astals Cid aa...@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 aa...@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
Re: Custom translated fields
El Dimecres, 10 de juny de 2015, a les 13:24:57, Jaroslaw Staniek va escriure: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view =markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. How does this work for languages with multiple plurals? Cheers, Albert It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
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|GenericName|Query|ExtraNames|X-KDE-Submenu)=(.+)};
-- to recognize extra fields of type localestring [1].
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 lu...@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
--
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
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On 10 June 2015 at 22:18, Burkhard Lück lu...@hube-lueck.de wrote: Am Mittwoch, 10. Juni 2015, 16:19:28 schrieb Alexander Potashev: 2015-06-10 14:24 GMT+03:00 Jaroslaw Staniek stan...@kde.org: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. and also in http://websvn.kde.org/trunk/l10n-kf5/scripts/applycontext.cpp?view=markup kpluginmetadata supports only translations for fields Name + Description, that is hardcoded in frameworks/kcoreaddons as well. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?vie w=markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? That is not sufficient, you need this hint for translated fields in applycontext.cpp, createdesktopcontext.pl and kpluginmetadata 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? -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
(CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view=markup -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view=markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
2015-06-10 14:24 GMT+03:00 Jaroslaw Staniek stan...@kde.org: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view=markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? Jaroslaw, Nice idea, I like it! Let's see if someone else in kde-i18n-doc comes up with a better strategy. -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
