Localization issues

Michael Bauer fios at akerbeltz.org
Mon Mar 19 15:43:46 UTC 2018


Sgrìobh Johnny Jazeix na leanas 18/03/2018 aig 19:40:
>
> Great news!
:)
> We have a script to automatically fill the translations from the Gtk+ 
> version. We also reworked a lot of strings so they couldn't be reused.
Yes though that would have worked a LOT better if the text blocks had 
been shorter
> I've commited it on stable branch.
Thanks!
> svn co svn+ssh://svn@svn.kde.org/home/kde/branches/stable/l10n-kf5/gd/ 
> <http://svn@svn.kde.org/home/kde/branches/stable/l10n-kf5/gd/> to get 
> the stable branch for gd.
> Then you put the file on messages/extragear-edu/gcompris_qt.po and to 
> commit: svn ci -m "your commit message"
> svn up, to update your local files with the one in the repository.
Ok thanks, will check if I have that set up, possibly GunChleoc did it 
for us last time from her machine
>
> Yes, that's one of the problem we have. Strings are mostly made by 
> developers where they should be done/reviewed by teachers/native 
> English people to simplify them.
Well, to be honest, the length of the blocks is not really something 
non-native devs couldn't do. Take
Help manual  activities/balancebox/ActivityInfo.qml:39

That almost 400 words in one string, containing 25 sentences. It would 
be much better if this was presented as 25 different strings.

I realise this may mean that devs have to be a creative and come up with 
a way of splitting blocks of text into separate strings (for the 
purposes of translation), at least where there is . ? ! or a line break. 
This is extra work once, but it will save many thousands of translator 
hours and prevent translators from just giving up.

It also means that if someone does fix the en-US, instead of 400 fuzzy 
matches, you get only 20 or 40 fuzzy matches, which is a lot less 
frustrating.

> There was already questions about this one 
> (https://mail.kde.org/pipermail/gcompris-devel/2018-March/005392.html 
> <https://mail.kde.org/pipermail/gcompris-devel/2018-March/005392.html>), 
> we'll remove it and change it to something more "conventional".
Great
> I guess we took the American one without specifying it. But yes, we 
> shouldn't use celebrations that are not the same everywhere.
I don't think there are many holidays which are the same globally - 
maybe we just tweaked the text to say [in many countries] or something 
like that
> We got a comment from the Chinese translator too regarding this. We'll 
> add that it's the system of most European and America countries and 
> add contexts for translators to know who we are positioning from.
It would also be good if we could at least introduce separate identities 
for maternal / paternal pairs, I think it would make a lot of 
translations easier without having to go too crazy with relationship terms.
>
> Yes, for sure, this is a place where we lack experience and need to 
> improve the quality. Most of the texts are written by non native 
> English and we don't have native people reviewing the texts. Do you 
> know people that would be interesting to help reviewing the activities?
Not off the top of my head. To be honest, having just been through the 
whole file, I was even hesitant to bring it up because of the large text 
block issue above, thinking "if I don't say anything, then our 
translation is fine and just the English is bad and I won't have to 
re-work yet again". But decided that would be a bit mean.

>
> There are several levels, a global one with the 7 new wonders, and the 
> other ones corresponding to other countries.
Ok
> Regarding the content, I think it was mostly inspired by wikipedia.
Which is not always the best source. I've seen quite a few articles on 
Asian topics which border on, well, let's say very flowery praise.
>
> Thank you for reporting the issues, it is always interesting to have 
> feedback to know where we should concentrate more.
>
You're welcome!

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20180319/eccbe5d0/attachment.html>


More information about the GCompris-devel mailing list