[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-i18n-doc
Subject: Re: Review Request 7126: message extraction of json files for scripty
From: "Milian Wolff" <mail () milianw ! de>
Date: 2014-11-23 21:21:28
Message-ID: 20141123212128.11307.16397 () probe ! kde ! org
[Download RAW message or body]
--===============6386418843700657417==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Nov. 22, 2014, 2:40 p.m., Milian Wolff wrote:
> > Just some small nitpicks, ignore at all. I just looked at our desktop files and \
> > indeed, they contain the translated GenericName which is nowhere displayed. Same \
> > for kate and KPluginSelector in kcmutils. So getting rid of that sounds fine with \
> > me! A name + description is all I can think of that needs to be translated.
> > thanks!
>
> Milian Wolff wrote:
> Looking at the current JSON files, they have contents such as this:
>
> {
> "KPlugin": {
> "Authors": [
> {
> "Email": "powerfox@kde.ru",
> "Name": "Evgeniy Ivanov"
> }
> ],
> "Category": "Version Control",
> "Name": "Git Support",
> "Name[bg]": "????????? ?? Git",
> "Name[bs]": "Git podrška",
> ...
> "Description": "This plugin integrates Git to KDevelop",
> "Description[bg]": "?a?? ????????? ??????? Git ? KDevelop",
> "Description[bs]": "Ovaj dodatak integriše Git u KDevelop",
> ...
> "Icon": "git",
> "Id": "kdevgit",
> "License": "GPL",
> "ServiceTypes": [
> "KDevelop/Plugin"
> ],
> "Version": "0.9"
> },
> "X-KDevelop-Category": "Global",
> "X-KDevelop-Mode": "GUI",
> "X-KDevelop-Interfaces": [
> "org.kdevelop.IBasicVersionControl", "org.kdevelop.IDistributedVersionControl"
> ],
> "X-KDevelop-Version": "@KDEV_PLUGIN_VERSION@"
> }
>
> I'm wondering whether we can somehow split out the translations? This will probably \
> require some changes to `kservice`, but I'd be willing to do that. What I have in \
> mind would be something like this:
> {
> "KPlugin": {
> "Authors": [
> {
> "Email": "powerfox@kde.ru",
> "Name": "Evgeniy Ivanov"
> }
> ],
> "Category": "Version Control",
> "Name": "Git Support",
> "Description": "This plugin integrates Git to KDevelop",
> "Icon": "git",
> "Id": "kdevgit",
> "License": "GPL",
> "ServiceTypes": [
> "KDevelop/Plugin"
> ],
> "Version": "0.9"
> },
> "X-KDevelop-Category": "Global",
> "X-KDevelop-Mode": "GUI",
> "X-KDevelop-Interfaces": [
> "org.kdevelop.IBasicVersionControl", "org.kdevelop.IDistributedVersionControl"
> ],
> "X-KDevelop-Version": "@KDEV_PLUGIN_VERSION@"
>
> "i18n": {
> "KPlugin": {
> "Name": {
> "bg": "????????? ?? Git",
> "bs": "Git podrška",
> ...
> },
> "Description": {
> "bg": "?a?? ????????? ??????? Git ? KDevelop",
> "bs": "Ovaj dodatak integriše Git u KDevelop",
> ...
> }
> }
> }
>
> This way, it's also going to be much simpler for us to update the files afterwards. \
> We just rip out the `i18n` entry and replace it with the current contents as read \
> from the translated gettext resources. For me as a developer this is also much more \
> convenient, as the translation "noise" is centralized at the end of the file and I \
> can concentrate on the stuff above.
> What do you think?
>
> Milian Wolff wrote:
> Ah and to go even further, we could "mark" entries as translateable through this as \
> well. Assume, for example, that I'm adding a new key to my JSON file that I need \
> translated for some reason. Then I could just add
> {
> "X-Please-Translate": "foo",
> "i18n": {
> ...,
> "X-Please-Translate": {}
> }
> }
>
> And in your `createjsoncontext.py` we could just iterate over the JSON objects we \
> find inside `i18n` and extract the corresponding original strings from above. \
> Again, what do you think?
> Burkhard Lück wrote:
> Milian Wolff 8 hours, 20 minutes ago (Nov. 23, 2014, 3:45 vorm.):
> > This way, it's also going to be much simpler for us to update the files \
> > afterwards. We just rip out the i18n entry and replace it with the current \
> > contents as read from the translated gettext resources.
>
> I do not need that for adding translations back from po files.
> The script filljsonfrompo.py is already properly working simulating a complete \
> translation roundtrip manually here (extraction of translations from json files in \
> a repo/folder into translation templates, translating all msgid's in locale x-test \
> + de and then adding the translation from l10n-kf5/lang/ folders back into the json \
> files. The only missing piece is the integration into scripty's workflow.
>
> But of course from a developer pov it makes sense to have all translations at the \
> end of the file.
> Milian Wolff 8 hours, 17 minutes ago (Nov. 23, 2014, 3:49 vorm.):
> > Ah and to go even further, we could "mark" entries as translateable through this \
> > as well. Assume, for example, that I'm adding a new key to my JSON file that I \
> > need translated for some reason
>
> That makes a lot of sense because we do not need an external definition of \
> translation fields for scripty. Adding a new field for translation developer only \
> have to ensure that the code is using translated entries of this field, but no \
> changes are required inside scripty's scripts, parsing json files during extraction \
> new translation fields can be automatically recognized.
> What about having the definition of all translation fields at the beginning of the \
> i18n part at one place, not spread across the whole i18n object like:
> "i18n": {
> {"translationfields": ["fieldname1" , "fieldname2" ... "fieldnameN"}
> "KPlugin": {
> "fieldname1": {
> "bg": "????????? ?? Git",
> "bs": "Git podrška",
> ...
> },
> "fieldname2": {
> "bg": "?a?? ????????? ??????? Git ? KDevelop",
> "bs": "Ovaj dodatak integriše Git u KDevelop",
> ...
> }
>
> ...
>
> "fieldnameN": {
> "bg": "?a?? ????????? ??????? Git ? KDevelop",
> "bs": "Ovaj dodatak integriše Git u KDevelop",
> ...
> }
> }
>
> Milian Wolff wrote:
> This might be problematic with "custom" fields, in a nested JSON hierarchy. E.g. in \
> your example above, how do you know that "fieldname1" is actually a member of \
> "KPLugin"? If we just take the hierarchy itself and stop at the next-to-last item, \
> we should get all information we need and are very flexible, no? It shouldn't be \
> too hard to code up either, I think.
> Burkhard Lück wrote:
> You mean "custom" fields somewhere in a nested hierarchy which should be \
> translated? Sure the extraction needs the info which field "Name" in the hierarchy \
> has to be translated, "KPlugin.Name" or "KPlugin.Authors.Name"? But how does the \
> extraction with your example "X-Please-Translate": "Name" know which value of \
> "Name" has to be extracted for translation: KPlugin.Name or KPlugin.Authors.Name ?
>
> Milian Wolff wrote:
> In my idea, we distinguish via the global selector path.
>
> {
> "Name": "1",
> "Foo": {
> "Name": "2",
> "Bar": {
> "Name": "3"
> }
> },
> "i18n": {
> "Name": {
> "de": "Eins",
> ...
> },
> "Foo": {
> "Name": {
> "de": "Zwei",
> ...
> },
> "Bar": {
> "Name": {
> "de": "Drei",
> ...
> }
> }
> }
> }
> }
>
> By iterating over the JSON objects in `json.i18n`, we should figure out that there \
> are these leaves: `json.i18n.Name`, `json.i18n.Foo.Name`, and \
> `json.i18n.Foo.Bar.Name`. Getting rid of the i18n inbetween, we can directly query \
> for the default value.
FTR: I just talked to Burkhard over IRC, and we agreed to keep things simple for now. \
Meaning: The fancy support for arbitrary translation keys will be done in the future \
if need arises.
- Milian
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://svn.reviewboard.kde.org/r/7126/#review11144
-----------------------------------------------------------
On Nov. 21, 2014, 4 p.m., Burkhard Lück wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://svn.reviewboard.kde.org/r/7126/
> -----------------------------------------------------------
>
> (Updated Nov. 21, 2014, 4 p.m.)
>
>
> Review request for Localization and Translation (l10n) and Milian Wolff.
>
>
> Repository: kde
>
>
> Description
> -------
>
> createjsoncontext.py extracts the fields KPlugin.Name and KPlugin.Description from \
> all json files in a repo into a gettext template (has to be postprocessed to be \
> valid)
> Only the field name is used as msgctxt as we do it with desktop files
>
> Question is which fields we need/want to support here.
> desktop files have Language, Keywords, X-KDE-Keywords, About, Description, Query,
> ExtraNames, X-KDE-Submenu as translatable fields
>
> But from the plugins desktop/json files in kdevelop afaik only Name + Description \
> (=Comment in desktop) are used in the GUI.
>
> create_json_files.sh is a modified/stripped down copy of create_desktop_files.sh \
> and has to be adapted for $mod with unterscores
>
>
> Diffs
> -----
>
> trunk/l10n-kf5/scripts/create_json_files.sh PRE-CREATION
> trunk/l10n-kf5/scripts/createjsoncontext.py PRE-CREATION
>
> Diff: https://svn.reviewboard.kde.org/r/7126/diff/
>
>
> Testing
> -------
>
> Manually running
> l10n-kf5/scripts$ python createjsoncontext.py $(find \
> ../../extragear/build/kdevelop_kdevplatform/ -name *.json) ../../extragear/build/ \
> generates a gettext template which needs to be processed further by \
> create_json_files.sh to get rid of some duplicate messages.
>
>
> Thanks,
>
> Burkhard Lück
>
>
--===============6386418843700657417==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://svn.reviewboard.kde.org/r/7126/">https://svn.reviewboard.kde.org/r/7126/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On November 22nd, 2014, 2:40 p.m. UTC, <b>Milian \
Wolff</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Just some small nitpicks, ignore at all. I just looked \
at our desktop files and indeed, they contain the translated GenericName which is \
nowhere displayed. Same for kate and KPluginSelector in kcmutils. So getting rid of \
that sounds fine with me! A name + description is all I can think of that needs to be \
translated.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">thanks!</p></pre> </blockquote>
<p>On November 23rd, 2014, 3:45 a.m. UTC, <b>Milian Wolff</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Looking at the current JSON files, they have contents such as this:</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;"><div class="codehilite" style="background: #f8f8f8"><pre \
style="line-height: 125%"> {
<span style="color: #BA2121">"KPlugin"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"Authors"</span><span \
style="color: #666666">:</span> [ {
<span style="color: #BA2121">"Email"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"powerfox@kde.ru"</span>, <span style="color: \
#BA2121">"Name"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"Evgeniy Ivanov"</span> }
],
<span style="color: #BA2121">"Category"</span><span \
style="color: #666666">:</span> <span style="color: #BA2121">"Version \
Control"</span>,
<span style="color: #BA2121">"Name"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"Git Support"</span>, <span \
style="color: #BA2121">"Name[bg]"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"????????? ?? Git"</span>, \
<span style="color: #BA2121">"Name[bs]"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"Git \
podrška"</span>,
...
<span style="color: #BA2121">"Description"</span><span \
style="color: #666666">:</span> <span style="color: #BA2121">"This plugin \
integrates Git to KDevelop"</span>, <span style="color: \
#BA2121">"Description[bg]"</span><span style="color: #666666">:</span> \
<span style="color: #BA2121">"?a?? ????????? ??????? Git ? \
KDevelop"</span>, <span style="color: \
#BA2121">"Description[bs]"</span><span style="color: #666666">:</span> \
<span style="color: #BA2121">"Ovaj dodatak integriše Git u \
KDevelop"</span>,
...
<span style="color: #BA2121">"Icon"</span><span style="color: \
#666666">:</span> <span style="color: \
#BA2121">"git"</span>,
<span style="color: #BA2121">"Id"</span><span style="color: \
#666666">:</span> <span style="color: \
#BA2121">"kdevgit"</span>,
<span style="color: #BA2121">"License"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"GPL"</span>,
<span style="color: #BA2121">"ServiceTypes"</span><span \
style="color: #666666">:</span> [
<span style="color: #BA2121">"KDevelop/Plugin"</span>
],
<span style="color: #BA2121">"Version"</span><span \
style="color: #666666">:</span> <span style="color: #BA2121">"0.9"</span> \
}, <span style="color: #BA2121">"X-KDevelop-Category"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"Global"</span>,
<span style="color: #BA2121">"X-KDevelop-Mode"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"GUI"</span>,
<span style="color: #BA2121">"X-KDevelop-Interfaces"</span><span \
style="color: #666666">:</span> [ <span style="color: \
#BA2121">"org.kdevelop.IBasicVersionControl"</span>, <span style="color: \
#BA2121">"org.kdevelop.IDistributedVersionControl"</span> ],
<span style="color: #BA2121">"X-KDevelop-Version"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"@KDEV_PLUGIN_VERSION@"</span> }
</pre></div>
</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I'm wondering whether we can somehow split out the \
translations? This will probably require some changes to <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">kservice</code>, but I'd be willing to do that. What I have in mind would \
be something like this:</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;"><div class="codehilite" \
style="background: #f8f8f8"><pre style="line-height: 125%"> {
<span style="color: #BA2121">"KPlugin"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"Authors"</span><span \
style="color: #666666">:</span> [ {
<span style="color: #BA2121">"Email"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"powerfox@kde.ru"</span>, <span style="color: \
#BA2121">"Name"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"Evgeniy Ivanov"</span> }
],
<span style="color: #BA2121">"Category"</span><span \
style="color: #666666">:</span> <span style="color: #BA2121">"Version \
Control"</span>,
<span style="color: #BA2121">"Name"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"Git Support"</span>, <span \
style="color: #BA2121">"Description"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"This plugin integrates Git to \
KDevelop"</span>,
<span style="color: #BA2121">"Icon"</span><span style="color: \
#666666">:</span> <span style="color: \
#BA2121">"git"</span>,
<span style="color: #BA2121">"Id"</span><span style="color: \
#666666">:</span> <span style="color: \
#BA2121">"kdevgit"</span>,
<span style="color: #BA2121">"License"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"GPL"</span>,
<span style="color: #BA2121">"ServiceTypes"</span><span \
style="color: #666666">:</span> [
<span style="color: #BA2121">"KDevelop/Plugin"</span>
],
<span style="color: #BA2121">"Version"</span><span \
style="color: #666666">:</span> <span style="color: #BA2121">"0.9"</span> \
}, <span style="color: #BA2121">"X-KDevelop-Category"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"Global"</span>,
<span style="color: #BA2121">"X-KDevelop-Mode"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"GUI"</span>,
<span style="color: #BA2121">"X-KDevelop-Interfaces"</span><span \
style="color: #666666">:</span> [ <span style="color: \
#BA2121">"org.kdevelop.IBasicVersionControl"</span>, <span style="color: \
#BA2121">"org.kdevelop.IDistributedVersionControl"</span> ],
<span style="color: #BA2121">"X-KDevelop-Version"</span><span \
style="color: #666666">:</span> <span style="color: \
#BA2121">"@KDEV_PLUGIN_VERSION@"</span>
<span style="color: #BA2121">"i18n"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"KPlugin"</span><span \
style="color: #666666">:</span> {
<span style="color: #BA2121">"Name"</span><span \
style="color: #666666">:</span> { <span style="color: \
#BA2121">"bg"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"????????? ?? Git"</span>, <span style="color: \
#BA2121">"bs"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"Git podrška"</span>,
...
},
<span style="color: #BA2121">"Description"</span><span \
style="color: #666666">:</span> { <span style="color: \
#BA2121">"bg"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"?a?? ????????? ??????? Git ? KDevelop"</span>, \
<span style="color: #BA2121">"bs"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"Ovaj dodatak integriše Git u \
KDevelop"</span>,
...
}
}
}
</pre></div>
</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">This way, it's also going to be much simpler for us to \
update the files afterwards. We just rip out the <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">i18n</code> entry and replace it with the current contents as read from the \
translated gettext resources. For me as a developer this is also much more \
convenient, as the translation "noise" is centralized at the end of the file and I \
can concentrate on the stuff above.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">What do you \
think?</p></pre> </blockquote>
<p>On November 23rd, 2014, 3:49 a.m. UTC, <b>Milian Wolff</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Ah \
and to go even further, we could "mark" entries as translateable through this as \
well. Assume, for example, that I'm adding a new key to my JSON file that I need \
translated for some reason. Then I could just add</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;"><div \
class="codehilite" style="background: #f8f8f8"><pre style="line-height: 125%">{ \
<span style="color: #BA2121">"X-Please-Translate"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"foo"</span>, <span \
style="color: #BA2121">"i18n"</span><span style="color: \
#666666">:</span> {
...,
<span style="color: #BA2121">"X-Please-Translate"</span><span \
style="color: #666666">:</span> {} }
}
</pre></div>
</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">And in your <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">createjsoncontext.py</code> we could just iterate over the JSON objects we \
find inside <code style="text-rendering: inherit;color: #4444cc;padding: \
0;white-space: normal;margin: 0;line-height: inherit;">i18n</code> and extract the \
corresponding original strings from above. Again, what do you think?</p></pre> \
</blockquote>
<p>On November 23rd, 2014, 12:34 p.m. UTC, <b>Burkhard Lück</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Milian Wolff 8 hours, 20 minutes ago (Nov. 23, 2014, 3:45 vorm.):</p> \
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">This way, it's also going to be much simpler for us to update the files \
afterwards. We just rip out the i18n entry and replace it with the current contents \
as read from the translated gettext resources.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I do not need that for adding translations back from \
po files. The script filljsonfrompo.py is already properly working simulating a \
complete translation roundtrip manually here (extraction of translations from json \
files in a repo/folder into translation templates, translating all msgid's in locale \
x-test + de and then adding the translation from l10n-kf5/lang/ folders back into the \
json files. The only missing piece is the integration into scripty's workflow.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">But of course from a developer pov it makes sense to \
have all translations at the end of the file.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Milian Wolff 8 hours, 17 minutes ago (Nov. 23, 2014, 3:49 vorm.):</p> \
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Ah and to go even further, we could "mark" entries as translateable through \
this as well. Assume, for example, that I'm adding a new key to my JSON file that I \
need translated for some reason</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">That makes a lot of sense because we do not need an \
external definition of translation fields for scripty. Adding a new field for \
translation developer only have to ensure that the code is using translated entries \
of this field, but no changes are required inside scripty's scripts, parsing json \
files during extraction new translation fields can be automatically recognized.</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">What about having the definition of all translation \
fields at the beginning of the i18n part at one place, not spread across the whole \
i18n object like:</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;"><div class="codehilite" \
style="background: #f8f8f8"><pre style="line-height: 125%"> <span style="color: \
#BA2121">"i18n"</span><span style="color: #666666">:</span> { {<span \
style="color: #BA2121">"translationfields"</span><span style="color: \
#666666">:</span> [<span style="color: #BA2121">"fieldname1"</span> , <span \
style="color: #BA2121">"fieldname2"</span> ... <span style="color: \
#BA2121">"fieldnameN"</span>}
<span style="color: #BA2121">"KPlugin"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"fieldname1"</span><span \
style="color: #666666">:</span> { <span style="color: \
#BA2121">"bg"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"????????? ?? Git"</span>,
<span style="color: #BA2121">"bs"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"Git \
podrška"</span>,
...
},
<span style="color: #BA2121">"fieldname2"</span><span \
style="color: #666666">:</span> { <span style="color: \
#BA2121">"bg"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"?a?? ????????? ??????? Git ? KDevelop"</span>, \
<span style="color: #BA2121">"bs"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"Ovaj dodatak integriše Git u \
KDevelop"</span>,
...
}
...
<span style="color: #BA2121">"fieldnameN"</span><span \
style="color: #666666">:</span> { <span style="color: \
#BA2121">"bg"</span><span style="color: #666666">:</span> <span \
style="color: #BA2121">"?a?? ????????? ??????? Git ? KDevelop"</span>, \
<span style="color: #BA2121">"bs"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"Ovaj dodatak integriše Git u \
KDevelop"</span>,
...
}
}
</pre></div>
</p></pre>
</blockquote>
<p>On November 23rd, 2014, 4:58 p.m. UTC, <b>Milian Wolff</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This \
might be problematic with "custom" fields, in a nested JSON hierarchy. E.g. in your \
example above, how do you know that "fieldname1" is actually a member of "KPLugin"? \
If we just take the hierarchy itself and stop at the next-to-last item, we should get \
all information we need and are very flexible, no? It shouldn't be too hard to code \
up either, I think.</p></pre> </blockquote>
<p>On November 23rd, 2014, 8 p.m. UTC, <b>Burkhard Lück</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">You \
mean "custom" fields somewhere in a nested hierarchy which should be translated? Sure \
the extraction needs the info which field "Name" in the hierarchy has to be \
translated, "KPlugin.Name" or "KPlugin.Authors.Name"? But how does the extraction \
with your example "X-Please-Translate": "Name" know which value of "Name" has to be \
extracted for translation: KPlugin.Name or KPlugin.Authors.Name ?</p></pre>
</blockquote>
<p>On November 23rd, 2014, 8:49 p.m. UTC, <b>Milian Wolff</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">In my \
idea, we distinguish via the global selector path.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;"><div \
class="codehilite" style="background: #f8f8f8"><pre style="line-height: 125%">{ \
<span style="color: #BA2121">"Name"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"1"</span>, <span \
style="color: #BA2121">"Foo"</span><span style="color: #666666">:</span> { \
<span style="color: #BA2121">"Name"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"2"</span>, <span \
style="color: #BA2121">"Bar"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"Name"</span><span style="color: \
#666666">:</span> <span style="color: #BA2121">"3"</span> }
},
<span style="color: #BA2121">"i18n"</span><span style="color: \
#666666">:</span> { <span style="color: #BA2121">"Name"</span><span \
style="color: #666666">:</span> {
<span style="color: #BA2121">"de"</span><span style="color: \
#666666">:</span> <span style="color: \
#BA2121">"Eins"</span>,
...
},
<span style="color: #BA2121">"Foo"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"Name"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"de"</span><span style="color: \
#666666">:</span> <span style="color: \
#BA2121">"Zwei"</span>,
...
},
<span style="color: #BA2121">"Bar"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"Name"</span><span style="color: \
#666666">:</span> {
<span style="color: #BA2121">"de"</span><span style="color: \
#666666">:</span> <span style="color: \
#BA2121">"Drei"</span>,
...
}
}
}
}
}
</pre></div>
</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">By iterating over the JSON objects in <code \
style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: \
0;line-height: inherit;">json.i18n</code>, we should figure out that there are these \
leaves: <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: \
normal;margin: 0;line-height: inherit;">json.i18n.Name</code>, <code \
style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: \
0;line-height: inherit;">json.i18n.Foo.Name</code>, and <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">json.i18n.Foo.Bar.Name</code>. Getting rid of the i18n inbetween, we can \
directly query for the default value.</p></pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">FTR: \
I just talked to Burkhard over IRC, and we agreed to keep things simple for now. \
Meaning: The fancy support for arbitrary translation keys will be done in the future \
if need arises.</p></pre> <br />
<p>- Milian</p>
<br />
<p>On November 21st, 2014, 4 p.m. UTC, Burkhard Lück wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for Localization and Translation (l10n) and Milian Wolff.</div>
<div>By Burkhard Lück.</div>
<p style="color: grey;"><i>Updated Nov. 21, 2014, 4 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kde
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">createjsoncontext.py extracts the fields KPlugin.Name \
and KPlugin.Description from all json files in a repo into a gettext template (has to \
be postprocessed to be valid)</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Only the field name is \
used as msgctxt as we do it with desktop files</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Question is which fields we need/want to support here. desktop files have \
Language, Keywords, X-KDE-Keywords, About, Description, Query, ExtraNames, \
X-KDE-Submenu as translatable fields</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">But from the plugins \
desktop/json files in kdevelop afaik only Name + Description (=Comment in desktop) \
are used in the GUI.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">create_json_files.sh is a \
modified/stripped down copy of create_desktop_files.sh and has to be adapted for \
$mod with unterscores</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Manually running l10n-kf5/scripts$ python \
createjsoncontext.py $(find ../../extragear/build/kdevelop_kdevplatform/ -name \
*.json) ../../extragear/build/ generates a gettext template which needs to be \
processed further by create_json_files.sh to get rid of some duplicate \
messages.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>trunk/l10n-kf5/scripts/create_json_files.sh <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>trunk/l10n-kf5/scripts/createjsoncontext.py <span style="color: \
grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="https://svn.reviewboard.kde.org/r/7126/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============6386418843700657417==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic