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

List:       kde-i18n-doc
Subject:    Re: i18n setup for RKWard
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2014-11-18 13:43:11
Message-ID: 7316344.g2eEsJvP22 () late
[Download RAW message or body]


On Tuesday 18 November 2014 12:01:29 Luigi Toscano wrote:
> On Tuesday 18 of November 2014 09:33:01 Thomas Friedrichsmeier wrote:
[...]
> Hi!
> The proper place for this kind of discussions (it's a question later) for
> this is the list kde-i18n-doc@kde.org, also because there are other people
> that can help (Burkhard Lueck for example).
> Please also check the recent thread "GCompris on its way to a public
> release" on the list, as it contains few answers.
> http://kde.markmail.org/thread/ynbkmj54h2rkkhx2

Hi Luigi,

thanks! I'll direct my follow-up to the list, then.
 
> See also:
> https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Syste
> ms

Yes, I've even written some of that page. But back than, my perspective was 
that of a "third party application" developer. Now I'm trying to figure out 
the KDE side.

Either way, reading extract_messages.sh, I think I'm beginning to understand 
how this is done, and why the files generated by our Messages.sh - quite 
fortunately for the moment - are not yet added to /l10n-kde4/templates/ .

> > 1. What we got so far:
> > - A "po" subdirectory with Messages.sh and rkward.pot
> 
> Please remove it, it's not needed.

Will do. Although, on second thought: To support building localized version 
from the source repo, directly (not just official releases), it probably makes 
some sense to keep a copy of the xy.po's in our repo, right? Only we'll have 
to make it explicit that these are just a copy.

> > - A bunch of existing translations for rkward.pot, named de.po
> 
> Those are the ones we should import on our SVN repository.

Ok, AFAICS, de.po would go to (e.g.) trunk/l10n-kde4/de/messages/playground-
edu/rkward.po . So I'll simply put them, there?

Follow-up questions:
1) Some of our translations are clearly in a bad shape. Currently our way of 
dealing with this is to apply a crude heuristic at installation time: If a 
translation is less than 80% complete, it is skipped. Is it better to apply a 
similar criterion, and only commit the translations that are at least say 50% 
complete, or is something always better than nothing, and I should commit all 
we got?
2) Whenever the time comes to move to kdereview, but also, when we start on 
porting to KF5, will everything be moved / copied around, automagically, or 
will I have to keep this in mind.

> > - Our translations are currently managed via translations.launchpad.net.
> > At
> > least one translation (es), there, also has a bunch of "suggestions"
> > pending, from someone not on the launchpad es translation team.
> 
> This should be cleaned; once the translations lands in our system, the
> translation page on launchpad should be closed to avoid confusion.

Of course.

> > 2. What will be added:
> > Right now, we are in the process of adding i18n to our plugins, which were
> > previously not translatable. In this process, several(!) additional .pot
> > files will start appearing. Messages.sh should already create one of these
> > (via scripts/extract_plugin_messages.py; in
> > po/plugins/rkward__analysis.pot), but at this point this is for testing
> > purposes, only, and translators are advised to hold work on this for
> > another short while, until all is reasonably stable.
> > 
> > Is there anything I should keep in mind about this _now_?
> 
> Once you add the Messages.sh files, scripty (our translation-handling
> script) will extract them; you can ask translators to ignore them, but it's
> possible that they will translate them anyway, at least partially,
> especially if they use translation memories. I wouldn't worry about this,
> people should read the list :)

Ok, well, as far as I understand, as long as Messages.sh does not place 
anything in $podir, nobody will ever get to see things they should not. 
Correct?
 
> > 3. For the somewhat longer term, could give me a rough picture, of how I
> > will retrieve translations when creating releases? Or will these be pushed
> > to our repo?
> 
> Albert can give more hints, see also the discussion I linked above as there
> are some answers.

Thanks. Looks comparable to what we have now (fetching translation updates 
from launchpad, before building the release). Will look into the details, 
later.

> PS. Do you have DocBook documentation that we can translate?

Yes. One very small, one pretty large docbook, both in "doc". Should I take 
any action about these?

Regards
Thomas
["signature.asc" (application/pgp-signature)]

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