[translations] Re: Links to changes PDF |
[ Thread Index |
Date Index
| More lilynet.net/translations Archives
]
Francisco Vila <paconet@xxxxxx> writes:
> Hello all,
>
> Web build system is a mess. Please look at this
>
> https://docs.google.com/spreadsheets/d/1_JleQNbXohBr5FaNEW-mSbCuT-OJI0msqGwVohoXpTM/edit?usp=sharing
>
> Here I'm focusing in Changes PDF only.
>
> What it is interesting is:
>
> [ca] uses the suffix, but the actual file is not found or generated.
> One is tempted to think, just don't use the suffix, but keep reading
>
> [de] does not use the suffix, but it maybe should, a German file is
> generated. Again, one is tempted to think, just use the suffix, but keep
> on reading
>
> [fr] does not use the suffix, text in web looks like it's [fr] but then
> links to [en] although a French file exists
May be different if your browser is set to prefer French?
> [it] uses the suffix, but both text in web and actual link ignore it,
> links to [en] although an Italian file does exist just like [fr]
>
>
> [fr] and [it] cases are shocking because the text/link pair does not
> match the macro being used, at all, and it fails in reverse ways.
>
> what. am. I. missing.
>
> It looks unmantainable without a huge lot of help. There are macro
> chains which are too long. There is too much post-processing of the
> output. I still haven't found a simple list of what we want to generate.
I think CCing the developer list here is in order. I think what this
may need is someone surveying the situation and figuring out a
strategy. I think part of the problem may stem from translators
starting from the English version and all of them developing their
specific strategy of dealing with translated links.
Maybe it would help if we made English language non-special, with en in
all its specific web files? That might make it more straightforward for
the translations to arrive at a uniform strategy since they then could
just copy what the English version does?
--
David Kastrup