[Qgis-tr] [Qgis-community-team] LTR Documentation soft freeze and plans for the future

[DelazJ]

Hi Alexandre, all

I also share your concerns about breaking translators' work. A year ago, we
somehow had this discussion [0] and set a roadmap, as follows:
- release the docs when the previous LTR "dies", ie in february (when 3.12
is out - in the practice, we released the docs almost a month later, due to
readthedocs theme testing)
- keep backporting changes for 2-4 months (ie until next release - when
3.14 is out)
- "seal" the released LTR docs and focus on the next version, until
february. Should it be a soft or hard freeze, I don't have a strong opinion
but I think we should clarify what is meant to be backported, to which
extent.

We should just write this somewhere, giving it a more "official" and
authoritative status (if it still OK)

Few points however:
- If we had a more regular push/pull between transifex/github/build, there
would be less gaps between the platforms and less complaints from
translators not finding corresponding strings. So while waiting for
automating, we could just (continue to) share the workload --> time to
really have regular doc meetings
- one "reason" of the regular backports is that (it's now one-click done
and) there's no priority about documentation. If we had a set of "features"
(give it a large meaning) to document for a release, it would probably be
easier to avoid a late backport when the changes do not concern the
priority features.
- splitting/restructuring files is not always predictable: sometimes, while
addressing an issue, you realize that this new feature does not well fit in
the current architecture, or that there's a better place for this old
section because there are more related features in newer versions and they
are described elsewhere... but I agree that split should happen in master
and avoided as far as possible in translated doc.

About the (long standing) static doc split, where would you put it? In the
website repo or a new one?

[0]
http://qgis-community-team.2324516.n4.nabble.com/Qgis-community-team-Releasing-QGIS-3-10-doc-when-3-10-quot-becomes-quot-LTR-fev-2020-td3121.html

Regards,
Harrissou

Le jeu. 6 août 2020 à 11:04, Alexandre Neto <senhor.neto at gmail.com> a
écrit :

> Hi all,
>
> Recently, richard has proposed that we avoid changing the documentation
> structure of the already released documentation, that is the LTR docs.
>
> I am +1 about this.
>
> When we change the structure of documentation, we need to reconfigure the
> translations and send it back to transifex. This is a manual procedure,
> that we can't forget to do, otherwise, what people is translating on
> transifex may "no longer exist" in the docs. Also, when we do this we
> scramble and loss a bunch of already translated strings, making translators
> life harder.
>
> This being said, with 3.16 on the horizon, and the LTR status in about 6
> or 7 months, it would be nice if we could plan any documentation
> restructuring before that.
>
> I have particular interest in moving the"static" content away from the
> "versioned" documentation. I am talking about the gentle introduction to
> GIS gentle introduction, the developers and the writing guideline, which do
> not depend on the QGIS version.
>
> Meanwhile, QGIS Server user manual has already been split from the Desktop
> manual, and lots of improvements are being made. \o/
>
> Regarding translations, we have been doing some testing and we will try to
> use transifex integration with github to allow automatic or semi-automatic
> string synchronization between the two platforms starting on 3.16.
>
> I would love to hear everyone's thoughts.
>
> Thanks,
>
> Alexandre Neto
> _______________________________________________
> Qgis-community-team mailing list for organizing community resources such
> as documentation, translation etc..
> Qgis-community-team at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-community-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-tr/attachments/20200808/814323df/attachment.html>