[Qgis-community-team] doc-test

[DelazJ]

Hi Alex,

Thanks for testing. Things seem promising as far I understand.
About transifex live, it's available for us. See screenshot (
https://paste.pics/c3aa8f6995dc130bdbcfcf818a5acc63) for the doc-test
project we create first.
I didn't explore the features to see how easy it's to set up for all our
resources and test as a regular translator (see the  provided GUI and
options) but at first glance there are things we can do.

Regards,
Harrissou


Le lun. 8 juin 2020 à 14:26, Alexandre Neto <senhor.neto at gmail.com> a
écrit :

> Hi,
>
> After Richard's work (thanks!) I did some fiddling in the doctest2.
>
> I have changed some existing rst files, and updated the corresponding po
> source files. Because Richard had already fixed the keys for those
> resources on .tx\conf, all worked well and transifex immediately picked the
> new strings and mark them as untranslated. Completing the resource
> translation on transifex resulted in an automated Pull Request to update
> the file on GihHub (sweat!)
>
> Then, I tried to create a brand new rst file and used shinx-intl to update
> the conf file (which led to some resources duplication), but the new
> resource was created and automatically picked by transifex. The
> opposite workflow also worked for that resource. once translated to 100% it
> created a PR with the translation.
>
> This made me think that the problem with the non-matching will only happen
> if start with already translated resources. Therefore, I am going to force
> transifex to thinks that all PO files are new and let it do the work for
> us. Fingers crossed!
>
> BTW, Harrissou, it seems that transifex live is only available for paying
> costumers :-(
>
> Thanks,
>
> Alexandre Neto
>
>
> On Sun, Jun 7, 2020 at 6:50 PM Richard 🌍 Duivenvoorde <richard at duif.net>
> wrote:
>
>> (mail was initially setup to Harrissou and Alexandre, partners in crime,
>> but I thought it would be better to share this with a greate audience
>> hoping more people will learn from this):
>>
>> We did some further experiment with github/transifex integration.
>>
>> To be able to do some further testing, and not being witheld by shortage
>> of qgis-repo permissions, I forked doc-test:
>>
>> https://github.com/rduivenvoorde/doc-test/
>>
>> and grant you both all rights in there...
>>
>> Then I created a 'new' qgistest organisation at github:
>>
>> https://www.transifex.com/qgistest/
>>
>> and also made you both maintainers.
>>
>> Then I created a new project by immidiatly going to github...
>> Transifex pulled english AND did not succeed to pull nl and fr
>> Maybe I should try again...
>>
>> Another way to start the project is to upload it first via sphinx-intl
>> and THEN integrate with github...
>> Ok... we tried that. It appears that with some fiddling we are able to
>> make this work:
>> https://www.transifex.com/qgistest/doctest2/dashboard/
>>
>> - first WITHOUT pushing anything to transifex, link the transifex
>> project to the github repo/branch using the directory config.yaml
>> https://github.com/rduivenvoorde/doc-test/tree/master/.tx
>>
>> - then using
>> make gettext
>> sphinx-intl update -p build/gettext -l en
>> create a .tx/config file
>> BUT!! all the 'keys' in that file will look like:
>> [doctest2.docs--user_manual--auth_system--auth_workflows]
>> and if you now try to push or pull, tx will complain it does not have
>> that resource(-key).
>> BUT (after the automatic github sync) the keys will look (looking at the
>> urls like
>>
>> https://www.transifex.com/qgistest/doctest2/locale-en-lc-messages-docs-user-manual-auth-system-auth-workflows-po--master/
>> you can edit the config file to refect those keys:
>>
>> [doctest2.locale-en-lc-messages-docs-user-manual-auth-system-auth-workflows-po--master]
>>
>> NOW you can both pull/push using tx AND transifex will automagically be
>> updated when sources change, OR github will be updated when a resource
>> is 100% translated (and optionally reviewed)..
>> There are some drawbacks... as the config file (we have 300 files in our
>> doc site) will have to be patched once, AND it will be harder to keep ip
>> uptodate
>>
>> We can already make this work for 3.10, but maybe it is better to wait
>> for 3.16 the next LTR ?
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-community-team/attachments/20200608/d68a65ec/attachment-0001.html>