Message266759
> From what I know of regional and country variations in spanish, [...] we (pydev) should not worry until there is an actual conflict from competing translations.
Totally agree.
> The patch has this table:
> + # version, target, isdev
> + ('3.4', WWWROOT + "/3.4", False),
> + ('3.5', WWWROOT + "/3.5", False),
> + ('3.6', WWWROOT + "/3.6", True),
> + ('2.7', WWWROOT + "/2.7", False)
Yes, it sticks to the current style: https://github.com/python/docsbuild-scripts/blob/master/build_docs.py#L33
> Why is 3.4 included, given that it now has the same status as 3.3?
What do you mean with "the same status" ? From my translator point of view, they still diverges, like in `Doc/library/zlib.rst:233`:
< "If the optional parameter *max_length* is supplied then the return value "
---
> "If the optional parameter *max_length* is non-zero then the return value "
And I don't think we can rely on certain releases being theorically identical to others, it look like an exception, look like it's not always true. I still prefer having a [clear tree of versions](https://github.com/AFPy/python_doc_fr) but we're (humans) only translating the latest version, we have scripts replicating our work to others.
Yet, if you tell me that there's work ongoing (that I clearly missed) to have every documentations, like by major version, converge to single one, with just some paragraphs added, it may simplify my hierarchy.
> Would it not be easier to default to False and only list 3.6?
Again I stick to the current style of the script, so ease its reading as a whole, but I agree, if we change it, let change it in another commit?
> Is it because you maintain separate branches for different 3.x branches? Given the presence of Version Changed and Version Added paragraphs, that is almost unnecessary. (Not having Version Deleted items is the main reason they might be.)
I am not aware of "Version Added" and "Version Changed" paragraphs, I understand that this is a policy to only add new paragraphs and never modify them inside the `3` major version ? This is cool for me, as said in my last paragraph, it may reduce the number of versionned `.po`, but it will not change the human workload (script replicating between po files ...).
> Is/are the main author/maintainer(s) of build_docs.py already nosy on the issue, to review?
Yes, I soon `nosy`ed Benjamin Peterson, look like he's the father of this script, if we trust commits here: https://github.com/python/docsbuild-scripts/commits/master
I even mailed him personally to speak about it (and he even replied once), but he's probably highly busy, and this is something I can understand. So here is my call on the issue to try to move this issue forward (I try to push this project less than once a month, to avoid buzzing everyone ears with this non-critical issue...).
> I cannot even though at least mildly interested. (The disconnect between interest and technical expertise is part of the problem with translation issues.)
Yes I also fully understand that the french translation of the documentation is not a point of interest for most of you upstream ^^ don't worry. |
|
Date |
User |
Action |
Args |
2016-05-31 16:35:01 | mdk | set | recipients:
+ mdk, terry.reedy, vstinner, benjamin.peterson, docs@python, zach.ware, abarry |
2016-05-31 16:35:01 | mdk | set | messageid: <1464712501.85.0.519007430633.issue26546@psf.upfronthosting.co.za> |
2016-05-31 16:35:01 | mdk | link | issue26546 messages |
2016-05-31 16:35:01 | mdk | create | |
|