-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[l10n] Add Basque (eu) locale and improve Spanish (es-ES) locale #10819
Conversation
Localization writing tips ✍️Seems you are updating localization 🌍 files. Thank you for contributing to the localization! 🎉 To make your PR perfect, here is a list of elements to check: ✔️
Deploy preview: https://deploy-preview-10819--material-ui-x.netlify.app/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution! 🙏
It looks like that we did not have this locale in the existing locales map, hence, it does not end up included in the table of available locales.
Could you please add this locale entry in the scripts/localeNames
file? 🤔
P.S. Please run yarn l10n
after doing it in order to generate the updated localization table statistics. 👌
Done! |
Spanish and Basque translations fixed and completed! 🥳 |
Is there anything else to do so you can merge this PR? |
Hey, thank you once again for your contribution! 🙏 |
@@ -5,6 +5,7 @@ export * from './deDE'; | |||
export * from './elGR'; | |||
export * from './enUS'; | |||
export * from './esES'; | |||
export * from './euES'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we shorten it? e.g. Chocobozzz/PeerTube#3956
export * from './euES'; | |
export * from './eu'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. That's a very good point and valuable discussion
@lajtomekadimon Could you confirm your position on this topic? Do you agree that having only eu
as a locale name makes sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both "eu" and "eu-ES" are fine as identifiers for the language, but I don't think eu
alone is a good idea in our case. euES
is the right choice here, mainly because that's the same criteria applied for the other languages.
All locale codes of packages/x-date-pickers/src/locales/
have both the language code and the country code. You have enUS
instead of en
for English, esES
instead of es
for Spanish, etc. Even languages like Icelandic or Japanese, which are only spoken on one country (at least to my knowledge), are isIS
and jaJP
.
I can't see the reason why Basque must be an exception and have a neutral country code.
And if that is not enough reason, keep in mind that a locale represents regional settings. It's much more than a language: it includes how numbers, dates and times are display, among other things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your points and they do make sense.
However, have you read the linked discussion? There are some compelling reasons and examples as to why only using eu
for this and some other locales makes sense. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I've read it. But that makes sense only if you apply the same criteria to all languages.
I'm not sure if changing the policy of all locale codes is related to this PR. I think that should be addressed on its own issue, since that affects all languages, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first look, it doesn't seem like a rare occasion. There is probably around at least a third of the locales that can have their country specific suffix removed. 🙈
@LukasTy I wonder if there are this many, e.g. ja
yes, en
no, fr
no, es
no, de
no.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oliviertassinari If we follow the path that DateFns
, Dayjs
and Moment
went, then all your mentioned examples are actually yes
, because they went with fr
for French (French), but add the country specific suffix for different locales.
It would especially make sense if we go the "inheritance"/"alias" route, where frCH
implementation would be:
import { fr } from './fr';
export const frCH = {
...fr,
theDifferentKey: 'theDifferentValue',
};
WDYT? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT? 🤔
@LukasTy Alright, here is my clearer take on it. The root of the problem here is this:
a. If we use eu_ES
and eu_FR
it would be confusing because these are the same
b. If we only use eu_ES
, it could be seen as unfair for people living in France
c. If we only use eu
, it could be seen as an exception to the rule
Overall, I think c. is the way, under the rule that we precise locales as much as possible but without being too precise when it could lead to confusion. This case is rare.
Then there are other cases:
- Languages that only exist in one locale, e.g. ja-JP. But https://github.com/iamkun/dayjs/blob/dev/src/locale/ja.js feels wrong, being more specific is clearer.
- Languages in different locales, e.g. en-UK, en-US. But https://github.com/iamkun/dayjs/blob/dev/src/locale/en.js feels wrong. It's not specific enough, I want to know exactly what
en
is. I wouldn't use this. I think that the only value ofen
is to help people who are short in time, who don't have the bandwidth to support too many locales, to know what's the best approximation (most popular locale).
My #suggestion would go like this:
- 👍 to merge this PR
- 👍 to create
en
as an alias ofen-US
- 👍 when we create
en-UK
, to have it as an extension ofen-US
- 👍 to not touch
es-ES
,fr-FR
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. Languages that only exist in one locale, e.g. ja-JP. But https://github.com/iamkun/dayjs/blob/dev/src/locale/ja.js feels wrong, being more specific is clearer.
I agree about the clarity aspect, but I feel that's what the libraries have addressed by adding a comment about the exact locale specifics, like in this case: https://github.com/date-fns/date-fns/blob/main/src/locale/pt-BR/index.ts#L11
I feel that having the comments would benefit our localization files even in this state to further increase the clarity. 🤔
This comment ties into the 3rd point as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comments
@LukasTy I think that the problem is that this is not clear from the codebase of developers. They have to open the docs or look at the IntelliSense.
I'm merging this. 👌 |
…#10819) Co-authored-by: David Andrés <dandres@binovo.es> Co-authored-by: Lukas <llukas.tyla@gmail.com>
Add Basque l10n for date pickers.