Resources fetched via resources.Get and similar should be language agnostic #5017
Comments
|
I agree with all of the above. I just realized that the resources permalink includes the language (I'd be surprised many people did) so I'm confident this can be changed with minimum codebreak. I personnaly can't find any use case for having two versions of a resources per language (since per language CSS can easily be achieved within one common stylesheet by targeting the lang attribute). For JS and the rest, Hugo Pipes gives you sufficient legroom to adapt your pipepline per language (language bundles, specific js lang variables outputted before the main script etc...). |
With the newly released Hugo Pipes, resources fetched and processed via `resources.Get` and similar was published to the relevant language sub folder when in multilingual mode. The thought behind that was maximum flexibility with support for `assetDir` per language. In practice this was a bad idea: * You get duplication of identical content, with added processing time * You end up with path issues that seem to be hard to find a way around (`@fa-font-path` is one example) This commit changes that. Now there is only one `assetDir` and if you, as one example, need to generate a CSS per langugage, you need to set the paths yourself. Fixes gohugoio#5017
With the newly released Hugo Pipes, resources fetched and processed via `resources.Get` and similar was published to the relevant language sub folder when in multilingual mode. The thought behind that was maximum flexibility with support for `assetDir` per language. In practice this was a bad idea: * You get duplication of identical content, with added processing time * You end up with path issues that seem to be hard to find a way around (`@fa-font-path` is one example) This commit changes that. Now there is only one `assetDir` and if you, as one example, need to generate a CSS per langugage, you need to set the paths yourself. Fixes gohugoio#5017
|
Yea, I label it as an Enhancement -- but it was obviously a mistake once I started to actually use it. |
With the newly released Hugo Pipes, resources fetched and processed via `resources.Get` and similar was published to the relevant language sub folder when in multilingual mode. The thought behind that was maximum flexibility with support for `assetDir` per language. In practice this was a bad idea: * You get duplication of identical content, with added processing time * You end up with path issues that seem to be hard to find a way around (`@fa-font-path` is one example) This commit changes that. Now there is only one `assetDir` and if you, as one example, need to generate a CSS per langugage, you need to set the paths yourself. Fixes gohugoio#5017
With the newly released Hugo Pipes, resources fetched and processed via `resources.Get` and similar was published to the relevant language sub folder when in multilingual mode. The thought behind that was maximum flexibility with support for `assetDir` per language. In practice this was a bad idea: * You get duplication of identical content, with added processing time * You end up with path issues that seem to be hard to find a way around (`@fa-font-path` is one example) This commit changes that. Now there is only one `assetDir` and if you, as one example, need to generate a CSS per langugage, you need to set the paths yourself. Fixes #5017
|
What if we use different hosting per language? (my case). I've noticed that the website relased under French language (hosted in server A) points to the JS/CSS files to the English website hosted in server B. I don't want to have host-dependency across sites. Is there any way to fall back to the previous behavior? |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Testing this with multiple languages with SCSS and font paths etc. shows that doing this per site/language, adding the language code to the permalink etc.), probably was a mistake and need some rethinking.
@fa-font-pathis my current head struggler)It is currently possible to define an assets dir per language, but I think we need to remove that possibility. I doubt that anyone uses it. This also would mean that if you want per-language resources, you would have to set the path yourself.
I think we need to do this sooner rather than later. I just added a second language to a site with a fair amount of SASS files, and doing that twice is doubling the processing time.
/cc @kaushalmodi @regisphilibert @onedrawingperday
The text was updated successfully, but these errors were encountered: