Skip to content
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.

Sign up for GitHub

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

Merged
merged 12 commits into from
Nov 10, 2023
Merged

[l10n] Add Basque (eu) locale and improve Spanish (es-ES) locale #10819

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
006f643
Add date picker basque i18n.
Oct 27, 2023
e74f49d
Apply code format.
Oct 27, 2023
e501cbf
Export euES locale in index.ts.
Oct 27, 2023
8d2d2ce
Add euES to export interfaces.
Oct 27, 2023
98176a5
Add Basque to localeNames.
Oct 27, 2023
9b9f158
Fix some Spanish translations and add translation for fieldClearLabel.
Oct 27, 2023
adff83c
Fix some Basque translations and add translation for fieldClearLabel.
Oct 27, 2023
5587c09
Update stats.
Oct 27, 2023
cbc01a1
Remove country specificity
LukasTy Nov 9, 2023
982d708
Make `l10n` work with only language (2 letters) locales
LukasTy Nov 9, 2023
3e3b16c
Fix l10n script to correctly work with 2 letter locale
LukasTy Nov 9, 2023
58ce7f6
Remove debug console
LukasTy Nov 9, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 87 additions & 0 deletions packages/x-date-pickers/src/locales/euES.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
import { PickersLocaleText } from './utils/pickersLocaleTextApi';
import { getPickersLocalization } from './utils/getPickersLocalization';
import { TimeViewWithMeridiem } from '../internals/models';

const views: Record<TimeViewWithMeridiem, string> = {
hours: 'orduak',
minutes: 'minutuak',
seconds: 'segunduak',
meridiem: 'meridianoa',
};

const euESPickers: Partial<PickersLocaleText<any>> = {
// Calendar navigation
previousMonth: 'Azken hilabetea',
nextMonth: 'Hurrengo hilabetea',

// View navigation
openPreviousView: 'azken bista ireki',
openNextView: 'hurrengo bista ireki',
calendarViewSwitchingButtonAriaLabel: (view) =>
view === 'year'
? 'urteko bista irekita dago, aldatu egutegi bistara'
: 'egutegi bista irekita dago, aldatu urteko bistara',

// DateRange placeholders
start: 'Hasi',
end: 'Bukatu',

// Action bar
cancelButtonLabel: 'Utxi',
clearButtonLabel: 'Garbitu',
okButtonLabel: 'OK',
todayButtonLabel: 'Gaur',

// Toolbar titles
datePickerToolbarTitle: 'Data aukeratu',
dateTimePickerToolbarTitle: 'Data eta ordua aukeratu',
timePickerToolbarTitle: 'Ordua aukeratu',
dateRangePickerToolbarTitle: 'Data tartea aukeratu',

// Clock labels
clockLabelText: (view, time, adapter) =>
`Aukeratu ${views[view]}. ${
time === null
? 'Denbora aukeraketarik gabe'
: `Aukeratutako denbora ${adapter.format(time, 'fullTime')} da`
}`,
hoursClockNumberText: (hours) => `${hours} ordu`,
minutesClockNumberText: (minutes) => `${minutes} minutu`,
secondsClockNumberText: (seconds) => `${seconds} segundu`,

// Digital clock labels
selectViewText: (view) => `Aukeratu ${views[view]}`,

// Calendar labels
calendarWeekNumberHeaderLabel: 'Astea zenbakia',
calendarWeekNumberHeaderText: '#',
calendarWeekNumberAriaLabelText: (weekNumber) => `${weekNumber} astea`,
calendarWeekNumberText: (weekNumber) => `${weekNumber}`,

// Open picker labels
openDatePickerDialogue: (value, utils) =>
value !== null && utils.isValid(value)
? `Aukeratu data, aukeratutako data ${utils.format(value, 'fullDate')} da`
: 'Aukeratu data',
openTimePickerDialogue: (value, utils) =>
value !== null && utils.isValid(value)
? `Aukeratu ordua, aukeratutako ordua ${utils.format(value, 'fullTime')} da`
: 'Aukeratu ordua',
// fieldClearLabel: 'Clear value',
LukasTy marked this conversation as resolved.
Show resolved Hide resolved

// Table labels
timeTableLabel: 'aukeratu data',
dateTableLabel: 'aukeratu ordua',

// Field section placeholders
fieldYearPlaceholder: (params) => 'Y'.repeat(params.digitAmount),
fieldMonthPlaceholder: (params) => (params.contentType === 'letter' ? 'MMMM' : 'MM'),
fieldDayPlaceholder: () => 'DD',
fieldWeekDayPlaceholder: (params) => (params.contentType === 'letter' ? 'EEEE' : 'EE'),
fieldHoursPlaceholder: () => 'hh',
fieldMinutesPlaceholder: () => 'mm',
fieldSecondsPlaceholder: () => 'ss',
fieldMeridiemPlaceholder: () => 'aa',
};

export const euES = getPickersLocalization(euESPickers);
1 change: 1 addition & 0 deletions packages/x-date-pickers/src/locales/index.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@ export * from './deDE';
export * from './elGR';
export * from './enUS';
export * from './esES';
export * from './euES';
Copy link
Member

@oliviertassinari oliviertassinari Nov 6, 2023 •
edited
Loading

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

Suggested change
export * from './euES';
export * from './eu';

Copy link
Member

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?

Copy link
Contributor Author

@lajtomekadimon lajtomekadimon Nov 7, 2023 •
edited
Loading

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.

Copy link
Member

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. 🤔

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Member

@LukasTy LukasTy Nov 9, 2023 •
edited by oliviertassinari
Loading

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? 🤔

Copy link
Member

@oliviertassinari oliviertassinari Nov 9, 2023 •
edited
Loading

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:

basque-mapS

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:

  1. 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.
  2. 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 of en 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 of en-US
  • 👍 when we create en-UK, to have it as an extension of en-US
  • 👍 to not touch es-ES, fr-FR, etc.

Copy link
Member

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.

Copy link
Member

@oliviertassinari oliviertassinari Nov 10, 2023 •
edited
Loading

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.

export * from './faIR';
export * from './fiFI';
export * from './frFR';
Expand Down
1 change: 1 addition & 0 deletions scripts/x-date-pickers-pro.exports.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,6 +128,7 @@
{ "name": "elGR", "kind": "Variable" },
{ "name": "enUS", "kind": "Variable" },
{ "name": "esES", "kind": "Variable" },
{ "name": "euES", "kind": "Variable" },
{ "name": "ExportedDateRangeCalendarProps", "kind": "Interface" },
{ "name": "ExportedDigitalClockProps", "kind": "Interface" },
{ "name": "ExportedMultiSectionDigitalClockSectionProps", "kind": "Interface" },
Expand Down
1 change: 1 addition & 0 deletions scripts/x-date-pickers.exports.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,6 +98,7 @@
{ "name": "elGR", "kind": "Variable" },
{ "name": "enUS", "kind": "Variable" },
{ "name": "esES", "kind": "Variable" },
{ "name": "euES", "kind": "Variable" },
{ "name": "ExportedDigitalClockProps", "kind": "Interface" },
{ "name": "ExportedMultiSectionDigitalClockSectionProps", "kind": "Interface" },
{ "name": "ExportedPickersCalendarHeaderProps", "kind": "TypeAlias" },
Expand Down