Current process uses sphinx to generate documentation out of the .rst files
and documentation, and uses some examples from the code.
Sphinx has some nice i18n tools that can extract translatable "messages"
already (for example here:
Had same in mind :-)
Should have some time late this week to dig into specifics of Airflow
process. And, need to explore how docs (source) organized, esp. whether
the parts to be translated are separate in some specific way.
On Sun, Jul 28, 2019 at 12:02 PM Jarek Potiuk
wrote:
> Such
Such translation could be performed on every master merge/ and for each
official release. I do not expect a lot of overhead/time/cost. We have to
run documentation building/release anyway and then translation of such
generated documentation should happen right after.
On Fri, Jul 26, 2019 at 6:29
Seems a suitable and reasonable approach, esp given current circumstances.
I would imagine the desire would be to then update anything in other
languages each time English updated? Or on a daily basis? Ongoing would
absolutely be important - in a predictable manner - rather than just
running
I understand the inclusivity need, and that's perfectly fine. However I am
afraid community will not have a process (and people) to keep the
documentation up-to-date - it will almost immediately become obsolete and
useless - we have like 10 commits coming in every day, most of them
including some
Thanks Kamil remind me in https://github.com/apachecn/airflow-doc-zh/issues/65
I agree with you multi languages point, I think Airflow leading page should
have multi languages
But for the documentation, I think it hard to up to date
I’m one of contributor of
I read the document and left a few simple comments. I would like us to
discuss about three things.
1. Architecture from the technical side.
I'm not sure if it's about creating a Airflow's site or creating
documentation for Airflow. For me, these are two independent things.
Pytorch consist of
