Sok Proposal

Johnny Jazeix jazeix at gmail.com
Wed Oct 19 08:18:31 UTC 2016


2016-10-18 15:29 GMT+02:00 Divyam Madaan <divyam3897 at gmail.com>:

> hi
>
>> >>
>> >> how do you plan to handle the translations for the words activity?
>> >>
>> > It still has to be thought properly to be implemented. We need the
>> > translations only to display words so for keys I will use english words
>> > only (qsTr can't be use with keys ) so I thought to keep an array as
>> values
>> > for eg: "words": ["go","do",..] and then use qsTr in the GCtext in model
>> > where we pass these words to translate them. What do you think can be a
>> > better idea to implement the same?
>> >
>>
>> I'm not sure it will be good to have everything in the main po file, so
>> maybe we can go with something like lang but it would mean one more file
>> for translators which do not make it easier for them...
>>
>> hi, I am not sure if it will be the right choice. Lang has its dataset in
> .json ( correct me if I am wrong) and it uses the parser to parse from it.
> When I was making categorization and had dataset in .json we planned to
> switched to .qml just because it makes translations easier for the
> translators  else they have to edit or make a new .json for their language.
> So in my view we can surely do something better which makes it easy both
> for the translators and dev team to maintain.
>

Hi, it's to be thought :). Another point is that some categories might make
sense for a language but not for all, can we provide external category
datasets (should they be translated or should we have one dataset per
language?)...

Johnny


>
>> >
>> >> What do you plan to do in the configuration for words that is different
>> >> from the configuration of images?
>> >>
>> > I thought I need to add all the languages in configuration as in lang
>> for
>> > the translation of words?
>> >
>>
>> Good thought :)
>>
>>
>> >> Johnny
>> >>
>> >>
>> -----
>>
> Thank you
> Regards
> Divyam Madaan
>
>> --------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/
>> 20161018/9db9abfe/attachment-0001.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> GCompris-devel mailing list
>> GCompris-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/gcompris-devel
>>
>>
>> ------------------------------
>>
>> End of GCompris-devel Digest, Vol 24, Issue 21
>> **********************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20161019/585b7b90/attachment-0001.html>


More information about the GCompris-devel mailing list