Closed claytonc closed 1 year ago
Work with the following changes:
/**
* Languages.
* @module constants/Languages
*/
module.exports = {
en: 'English',
de: 'Deutsch',
nl: 'Nederlands',
ro: 'Română',
ja: '日本語',
pt: 'Português',
'pt-BR': 'Português (Brasil)',
es: 'Spanish',
it: 'Italian',
eu: 'Euskara',
};
config.settings = {
...config.settings,
isMultilingual: false,
supportedLanguages: ['pt-BR'],
defaultLanguage: 'pt-BR',
};
This is related to https://github.com/plone/volto/issues/3786
This is related to #3786
Two problems, both related to the pt_BR language:
1 - causes duplicate API requests - reported by you; 2 - crash when accessing "Page not found 404" - reported by me;
But the second problem is more serious where it leaves the site unavailable.
@claytonc @wesleybl @ericof
I tried to reproduce it in vanilla Volto: 1.- config:
config.settings.supportedLanguages = ['pt-BR']; config.settings.defaultLanguage = 'pt-BR';
2.- Go to the control panel, set Brasilian Portuguese as default and supported in Languages.
3.- Check Volto:
Tried also with the cookiecutter, and I saw that the wizard is generating pt-br
(in lowercase), which @ericof, we would have to address. The rest, all is good, no duplicated requests. @claytonc why are you changing the constants? You should not have to do that.
@sneridagh yes. Using pt-BR
instead of pt-br
in the Volto configuration solves the problem of duplicate requests. See my comments on #3786. But I have two questions:
I18N_LANGUAGE
cookie is recorded as pt_BR
. After reading, it is converted back to pt-BR
. I wonder if we couldn't record the cookei already with pt-BR
, to avoid so many conversions.@wesleybl I think there was a limitation, I can't remember on which side. So Plone uses the dashed identifier (this is needed for multilingual sites), so it should be like this, and cannot be changed, then LC_MESSAGES and react-intl uses the lowercase_uppercase format, and the solution was to transform (there is a helper for it: https://github.com/plone/volto/blob/master/src/helpers/Utils/Utils.js#L183) one to another in runtime.
I don't know if it's feasible use all lowercases (with dash) from the LC_MESSAGES and react-intl point of view (I think that the answer was that we can't). We can't change how Plone does things with the cookie either, since that would be breaking a lot of things and internals from Plone itself... So I think we are quite handcuffed in this one, I'm afraid.
However, feel free to investigate and try to find a better solution. Maybe @robgietema can also weigh in on this one.
@sneridagh
Changing the constants from "pt_BR" to "pt-BR" was necessary to solve the problem of a Volto site stopping working after a page not found ( 404 error). This problem did not occur in previous versions of the Volto.
Also, changing "supportedLanguages" and "defaultLanguage" to "pt-BR" was necessary for the translations to work correctly. Translations made in our addons were not working in pt_BR on Volto.
Changing:
1.- configuration: config.settings.supportedLanguages ​​= ['pt-BR']; config.settings.defaultLanguage = 'pt-BR';
2.- go to the control panel, set Brasilian Portuguese as default and supported in Languages.
3.- and access the url for example http://localhost:3000/abc, the following error occurs and it is not displayed on the page not found, but this time the site is not down.
"RangeError: Incorrect locale information provided"
4.- adding 'pt-BR': 'Português (Brasil)'
to the constants (Laguages.js), access http://localhost:3000/abc, page not found is displayed.
5.- changing a setting and the constants: config.settings.supportedLanguages ​​= ['pt-br']; config.settings.defaultLanguage = 'pt-br';
6.- access http://localhost:3000/abc, page not found in English displayed.
I've attempted to fix this in https://github.com/plone/volto/pull/4741 -- note that pt-br
is the format expected in volto config.
Describe the bug
Error when accessing a non-existent URL in the browser, when the language code is pt-br, the "404 Not Found page" is not displayed and crash frontend.
When select language code en, the "404 Not Found page" is displayed.
To Reproduce
Steps to reproduce the behavior:
Expected behavior I hope the "display a 404 Not Found page" is displayed.
Software (please complete the following information):