You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I started some tests with Axelor and I think it's an incredible product.
As a first step to use it in my country, Brazil, I went to check what it would take to create the translation into Brazilian Portuguese.
Axelor has support for Portuguese in the European variant but it is quite different from the Brazilian Portuguese and we have great difficulty understanding the European Portuguese, so the translation is an important step for use here in Brazil.
Studying the Axelor development kit I checked how the i18n files are loaded into the database and the way they are used later in the bundle and the locale definition.
I realized that the definition of the locale could generate a problem for the portguês brazil, or other locales that use the Region / Country.
The acronyms of locale with country follow a pt_BR or pt-BR format (IETF BCP 47)
The initialization of these locales in java should be done following the calls as an example in pt_BR.
Locale locale = new Locale ("pt", "BR");
or in the case of IETF BCP 47
Locale locale = Locale.forLanguageTag(“pt-BR");
In Axelor core AppFilter the locale is initialized always in constructor.
This way if the language is set with the country variant as "pt_br" the call would look like this.
Locale locale = new Locale (“pt_br");
Although this call does not generate errors for the java it does not load this locale in a valid way and starts to treat the definition as locale “en" for all cases of formatting, for example of dates and values.
So as a first step to allow correct use in languages that include country code must be made adjustments in this code.
Also the class I18nBundle attempts to localize the translation using locale.getLanguage(), in the case of a properly initialized locale this method will return only the language code and not the country code.
final String lang = locale.toString().toLowerCase();
The locale's toString() call would return "pt_BR" in locale cases with country and only "pt" in cases where they have not set the country code. The call to toLowerCase would be useful because postgres, for example, makes case-sensitive queries.
The text was updated successfully, but these errors were encountered:
Hi,
Can you explain how can I put the blue buttons inside a dropdown. How are they being created inside axelor's codebase? I am a beginner and if I have posed this question in a wrong place, please let me know.
Hello,
I started some tests with Axelor and I think it's an incredible product.
As a first step to use it in my country, Brazil, I went to check what it would take to create the translation into Brazilian Portuguese.
Axelor has support for Portuguese in the European variant but it is quite different from the Brazilian Portuguese and we have great difficulty understanding the European Portuguese, so the translation is an important step for use here in Brazil.
Studying the Axelor development kit I checked how the i18n files are loaded into the database and the way they are used later in the bundle and the locale definition.
I realized that the definition of the locale could generate a problem for the portguês brazil, or other locales that use the Region / Country.
The acronyms of locale with country follow a pt_BR or pt-BR format (IETF BCP 47)
The initialization of these locales in java should be done following the calls as an example in pt_BR.
Locale locale = new Locale ("pt", "BR");
or in the case of IETF BCP 47
Locale locale = Locale.forLanguageTag(“pt-BR");
In Axelor core AppFilter the locale is initialized always in constructor.
https://github.com/axelor/axelor-development-kit/blob/b41fc083ed10a348ce7fba0f60aaf6e8486f3640/axelor-core/src/main/java/com/axelor/app/internal/AppFilter.java#L47
https://github.com/axelor/axelor-development-kit/blob/b41fc083ed10a348ce7fba0f60aaf6e8486f3640/axelor-core/src/main/java/com/axelor/app/internal/AppFilter.java#L59
This way if the language is set with the country variant as "pt_br" the call would look like this.
Locale locale = new Locale (“pt_br");
Although this call does not generate errors for the java it does not load this locale in a valid way and starts to treat the definition as locale “en" for all cases of formatting, for example of dates and values.
So as a first step to allow correct use in languages that include country code must be made adjustments in this code.
Also the class I18nBundle attempts to localize the translation using locale.getLanguage(), in the case of a properly initialized locale this method will return only the language code and not the country code.
this way I suggest the exchange of the call
https://github.com/axelor/axelor-development-kit/blob/b41fc083ed10a348ce7fba0f60aaf6e8486f3640/axelor-core/src/main/java/com/axelor/i18n/I18nBundle.java#L83
by the call
final String lang = locale.toString().toLowerCase();
The locale's toString() call would return "pt_BR" in locale cases with country and only "pt" in cases where they have not set the country code. The call to toLowerCase would be useful because postgres, for example, makes case-sensitive queries.
The text was updated successfully, but these errors were encountered: