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

List:       kde-i18n-doc
Subject:    [GCompris] Dataset translations
From:       Johnny Jazeix <jazeix () gmail ! com>
Date:       2024-01-03 20:33:36
Message-ID: CAEtcAPEB=pepDjpsfcAotpo-y8_2h4cjR7abHUK_ni8tccrwRw () mail ! gmail ! com
[Download RAW message or body]

Hi,

Johannes made a MR (
https://invent.kde.org/education/gcompris/-/merge_requests/166) for
GCompris to convert the dataset of wordsgame from json to po files (and
vice versa) to have the same workflow as translators are used to.

The advantages I can see are:
* it will be like the usual workflow, no need to retrieve the file in
GCompris source code.
* less risk to do errors in the json (we have a gitlab workflow to validate
json files but it can still prevent a bad first commit if directly
committed to master)

The drawbacks I see are:
* it is not a translation of text, more a workaround to use the usual po
file to adapt datasets in different locales
* using this way will limit to 25 levels maximum of game. I don't think
it's a real issue as we recommand to have less than 10 levels.
* the list of words can be very long, so maybe less readable than a json
file but as just above not sure if it is a drawback.

As it mostly affects translators, what is your opinion of it? Existing
translations will be kept if we merge this MR so the ones who will be
mostly impacted will be new translations (but it can be useful for existing
locales to rework the datasets if needed).
If we go with it, can you check the po we generated in comment and help
with what could be useful as msgctxt and msgid?

This approach can be generalized to other datasets which looks like the
same if it is good for you.

Cheers,

Johnny

[Attachment #3 (text/html)]

<div dir="ltr"><div>Hi,</div><div><br></div><div>
<span class="gmail-note-header-author-name gmail-gl-font-weight-bold">Johannes</span> \
made a MR (<a href="https://invent.kde.org/education/gcompris/-/merge_requests/166">https://invent.kde.org/education/gcompris/-/merge_requests/166</a>) \
for GCompris to convert the dataset of wordsgame from json to po files (and vice \
versa) to have the same workflow as translators are used \
to.</div><div><br></div><div>The advantages I can see are:</div><div>* it will be \
like the usual workflow, no need to retrieve the file in GCompris source \
code.</div><div>* less risk to do errors in the json (we have a gitlab workflow to \
validate json files but it can still prevent a bad first commit if directly committed \
to master)<br></div><div><br></div><div>The drawbacks I see are:</div><div>* it is \
not a translation of text, more a workaround to use the usual po file to adapt \
datasets in different locales<br></div><div>* using this way will limit to 25 levels \
maximum of game. I don&#39;t think it&#39;s a real issue as we recommand to have less \
than 10 levels.</div><div>* the list of words can be very long, so maybe less \
readable than a json file but as just above not sure if it is a \
drawback.<br></div><div><br></div><div> <div>As it mostly affects translators, what \
is your opinion of it? Existing translations will be kept if we merge this MR so the \
ones who will be mostly impacted will be new translations (but it can be useful for \
existing locales to rework the datasets if needed).<br></div><div>If we go with it, \
can you check the po we generated in comment and help with what could be useful as \
msgctxt and msgid?</div><div><br></div><div>This approach can be generalized to other \
datasets which looks like the same if it is good for you.<br></div><div><br></div>

</div><div>Cheers,</div><div><br></div><div>Johnny<br></div></div>



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