[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: GNOME appdata files translation
From:       "Yuri Chornoivan" <yurchor () ukr ! net>
Date:       2013-11-05 6:34:42
Message-ID: op.w52cj4uyl2zvei () localhost ! localdomain
[Download RAW message or body]

написане Mon, 04 Nov 2013 06:35:23 +0200, T.C. Hollingsworth  
<tchollingsworth@gmail.com>:

> Hi Yuri, Albert, other translators!
>
> On Sat, Nov 2, 2013 at 1:55 AM, Yuri Chornoivan <yurchor@ukr.net> wrote:
>> Hi,
>>
>> GNOME developers proclaim their goal to add appdata files [1] to every
>> package and to hide for GNOME users every package without such files in  
>> 1
>> year (GNOME 3.14).
>>
>> So far, even Fedora/KDE package manager (Apper) cannot show appdata by
>> default (should be recompiled with a specific option). So there is no  
>> KDE
>> distribution that can show appdata.
>
> Our very awesome Rex Dieter is already working on getting that going.
> I, for one, can't wait to have screenshots and other juicy goodness in
> my apper. :-)
>
>> Form the technical PoV, is it possible for scripty to extract messages  
>> from
>> such files (should they be added to the repos) and merge them back?
>
> Attached is a rough patch against l10n-kde4/scripts to implement this.
>
> A fair bit of it is copy/pasted/otherwise heavily inspired from the
> .desktop file stuff, since it's sort of doing the same thing.  It
> might make sense to combine a couple of the scripts and just add args
> to do different stuff depending on whether it's appdata or .desktop,
> but I wanted to keep it simple for now.
>
> Things I've tested:
> - createappdatacontext.py spits out acceptable looking POTs when fed
> reasonable contrived arguments (example at [1])
> - merge_appdata_files.sh runs applyappdatacontext.py successfully when
> fed reasonable contrived arguments and spits out a valid combined XML
> file
>
> Things I've not tested:
> - findappdatafiles, though how bad can you screw up changing arguments  
> to find?
> - update_translations, because oh my god I already need a drink ;-)
>
> Also, the indentation on translated entries looks nothing like the
> originals, despite a chunk of awkward code that tries to remedy that.
> Not sure whether it's possible to fix that, or if we need some sort of
> project-wide policy on indentation to match what the script will do,
> or if nobody cares.
>
> I wouldn't be the least bit surprised if I missed something,
> especially in update_translations, so please do have a look and let me
> know how badly I would have broken scripty. ;-)
>
> -T.C.
>
> [1] https://gist.github.com/tchollingsworth/2e708dd8925c9ff2d939

Hi,

If I understand things correctly, "name" for AppData is taken from desktop  
file (it is unclear though if the corresponding translation will be  
selected).

It is also interesting what will happen with partial translations  
(translated summary and untranslated description and vice versa)? Will  
they be used or discarded. What will I find in xxx Software Center when  
the search term is e.g. "Calculator"? Both localized and non-localized  
results or just unlocalized ones?

Using appdata.its from Richard's page [1] leads to translation by  
paragraph for multi paragraph descriptions, like this (I run it as  
"itstool -i appdata.its -j inkscape.appdata.xml -o translated.xml uk.mo")

<description>
<p>Something</p>
<p xml:lang="uk">Blah-blah</p>
</description>

intltool translates this as

<description>
<p>Something</p>
</description>
<description xml:lang="uk">
<p>Blah-blah</p>
</description>

What is the right way?

Thanks in advance for your comments.

Best regards,
Yuri

[1] http://people.freedesktop.org/~hughsient/appdata/appdata.its
[prev in list] [next in list] [prev in thread] [next in thread]