<div dir="ltr"><div dir="ltr">Hi Alexandre, all</div><div dir="ltr"><br></div><div>I also share your concerns about breaking translators' work. A year ago, we somehow had this discussion [0] and set a roadmap, as follows:</div><div>- 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)<br></div><div>- keep backporting changes for 2-4 months (ie until next release - when 3.14 is out)</div><div>- "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. <br></div><div><br></div><div>We should just write this somewhere, giving it a more "official" and authoritative status (if it still OK)<br></div><div><br></div><div>Few points however:</div><div>- 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<br></div><div>- 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.<br></div><div>- 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.</div><div><br></div><div>About the (long standing) static doc split, where would you put it? In the website repo or a new one?<br></div><div><br></div><div>[0] <a href="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" target="_blank">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</a></div><div><br></div><div>Regards,</div><div>Harrissou</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 6 août 2020 à 11:04, Alexandre Neto <<a href="mailto:senhor.neto@gmail.com" target="_blank">senhor.neto@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi all,<div dir="auto"><br></div><div dir="auto">Recently, richard has proposed that we avoid changing the documentation structure of the already released documentation, that is the LTR docs. </div><div dir="auto"><br></div><div dir="auto">I am +1 about this.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Meanwhile, QGIS Server user manual has already been split from the Desktop manual, and lots of improvements are being made. \o/</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I would love to hear everyone's thoughts.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Alexandre Neto</div></div>
_______________________________________________<br>
Qgis-community-team mailing list for organizing community resources such as documentation, translation etc..<br>
<a href="mailto:Qgis-community-team@lists.osgeo.org" target="_blank">Qgis-community-team@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-community-team</a></blockquote></div></div>