Re: Technical feasibility to translate a project on Github

[Daniel Mustieles García <daniel mustieles gmail com>]

Thanks for the quick response!

Doing a quick review of the PO file I see the strings are (in the most of cases) very short and often used in GNOME, so using a translation memory would be really easy to have it done.

Yes, I was thinking in the same examples. Just adding a link in the module's page in DL to directly open an MR in the target repo would be a medium-directly way to have it.

Taking this into account, I give a +1 for having this available for translation in Damned Lies. Of course, now it's time to hear another coordinator's opinion about this.

Regards

El mar., 13 oct. 2020 a las 13:09, Thibault Martin (<mail thibaultmart in>) escribió:

Hello Daniel and thanks for your answser,

There seems to be 1112 strings to translate for the Flatpak software
only.

Those strings are in files in the PO format. I’m not quite sure about
how (often) those are generated, but if we need adjustments, I’m
quite sure we can ask them a few things. Let’s not forget Alexander
Larsson is working on it :)

The files can be found here:
https://github.com/flatpak/flatpak/tree/master/po

As of today, DL is used to follow the translation status of several
projects it can't commit on. The two examples I have in mind are the
freedesktop and Librem 5 ones. To commit our translations, someone
manually opens a MR on the Gitlab, and then reports to their
translation coordinator. It’s far from ideal, but still preferable to
a completely manual process in my opinion.

Best,


Le mar. 13 oct. 2020 à 12:58, Daniel Mustieles García
<daniel mustieles gmail com> a écrit :
> Hi Thibault,
>
> I have some questions about this, hope you can help us with them
>
> 1 .To have a better idea about the necessary work for this, how many
> translatable strings (aprox) Flatpak Software has?
>
> 2. Are those translatable strings in a PO file format? If answer is
> no, which format does it use and which tool is recommended for it?
>
> 3 - If finally DL is not able to directly commit translations, how
> will be the workflow to send and commit them?
>
> In a first stage I would not opposite to this idea, but I would like
> to solve these questions before giving a final vote (just my personal
> opinion about this, it would be necessary other coordinator's
> opinion).
>
> Thanks in advance
>
> El vie., 9 oct. 2020 a las 14:22, Thibault Martin
> (<mail thibaultmart in>) escribió:
>> Hello,
>>
>>  Thanks for this quick answer Claude. So that solves the technical
>>  feasibility.
>>
>>  Now the audience for this question would probably be the translation
>>  coordinators: would we accept to take the responsibility of
>> translating
>>  flatpak software?
>>
>>  Best,
>>
>>  Le jeu. 8 oct. 2020 à 23:12, Claude Paroz <claude 2xlibre net> a
>>  écrit :
>>  > Le 08.10.20 à 14:13, Thibault Martin a écrit :
>>  >> Hello,
>>  >>
>>  >> Flatpak doesn't have a proper translation platform. So far people
>>  >>  retrieve and submit po files manually.
>>  >>
>>  >> I know Flatpak doesn’t necessarily want to be too associated
>> with
>>  >> GNOME  so it doesn’t shy out other systems.
>>  >> Still, a translation provided by one of the major DE could be an
>>  >> huge  improvement to today’s situation.
>>  >>
>>  >> I have two questions here:
>>  >> * Would we accept to take responsibility of Flatpak’s
>> translations?
>>  >> * Is it technically feasible for DL to handle the translations
>> of a
>>  >>  project stored on GitHub?
>>  >>
>>  >> If we answer "yes" to both, I would offer to Flatpak’s team to
>>  >> take care  of their translations, which they may or may not
>> accept.
>>  >
>>  > Hi Thibault,
>>  >
>>  > There is more or less two level of translation supports in D-L.
>>  > The first one is "simply" a status of current module translations
>> +
>>  > updated pot and merged po files ready for translators to use.
>>  > That's the case for all freedesktop modules.
>>  >
>>  > The second is ability to commit translations from the Web
>> interface.
>>  > We do not support Github currently for this feature.
>>  >
>>  > So I would say that hosting translation stats would be fine IMHO.
>>  > Adding commit support is another story, even if it should not be
>> so
>>  > much effort (to be evaluated, still).
>>  >
>>  > Claude
>>  > --
>>  > www.2xlibre.net
>>  > _______________________________________________
>>  > gnome-i18n mailing list
>>  > gnome-i18n gnome org
>>  > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>>
>>  _______________________________________________
>>  gnome-i18n mailing list
>> gnome-i18n gnome org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n