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

List:       kde-i18n-doc
Subject:    Re: [GCompris] Dataset translations
From:       Luigi Toscano <luigi.toscano () tiscali ! it>
Date:       2024-01-03 20:51:24
Message-ID: e33bd9ef-99ed-1561-cad2-a04d7e74f6a1 () tiscali ! it
[Download RAW message or body]

Johnny Jazeix ha scritto:
> 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).

IMHO I don't think this is a "proper" usage of gettext-based translations.

These are data files which have different kind of information in different
languages, so it makes sense to keep them as data files.

About the two points you mentioned as advantages:
- the first one is not really a problem as those files are almost never going
to change (you can see similar files in other education/ projects);
- about validation, we can't prevent any breakages if people commit directly
to master, and that's the case also for the code. So I would say the existing
validation is more than enough.

Ciao
-- 
Luigi
[prev in list] [next in list] [prev in thread] [next in thread]