i18n test locale not translating everything

[flash1293]

Some phrases in the Kibana are not translated properly using the en-xa test locale. I didn't find a pattern yet what causes this, all places I've found seem to use i18n.translate or FormattedMessage properly:

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

I did not know about this en-xa locale, however from a quick grep I think this is an expected behavior of this locale?

kibana/packages/kbn-i18n/src/core/pseudo_locale.ts

Lines 24 to 45 in 848121f

	const PSEUDO_ACCENTS_LOCALE = 'en-xa';
	export function isPseudoLocale(locale: string) {
	return locale.toLowerCase() === PSEUDO_ACCENTS_LOCALE;
	}
	/**
	* Replaces every latin char by pseudo char and repeats every third char twice.
	*/
	function replacer() {
	let count = 0;
	return (match: string) => {
	// if `match.length !== 1`, then `match` is html tag or markdown link address, so it should be ignored
	if (match.length !== 1) {
	return match;
	}
	const pseudoChar = pseudoAccentCharMap[match] || match;
	return ++count % 3 === 0 ? pseudoChar.repeat(2) : pseudoChar;
	};
	}

Or is the issue here that every message should be displayed with this en-xa locale and are not?

[flash1293]

Exactly, from my understanding every message should be displayed with this locale. Platform is probably the wrong team. @Bamieh do you know who to ping?

[pgayvallet]

Platform is probably the wrong team

I see /src/legacy/server/i18n/ @elastic/kibana-platform in CODEOWNERS, so maybe we are the good one. @joshdover are we officially in charge of packages/kbn-i18n ?

[joshdover]

No I think that is just outdated from before localization was split out from the Platform team. @Bamieh should be able to help us out here, and I think we should reassign the code owners to @elastic/pulse

[elasticmachine]

Pinging @elastic/kibana-localization (Team:Localization)

[Bamieh]

We do have a localization team on github so i think it should go there @elastic/kibana-localization. (Here is a pr to update the file #63354)

All i18n messages should be translated using the en-xa to the psuedo locale. So I believe this is a bug. I'll try to have this prioratized to investigate further.

[joshdover]

@Bamieh friendly bump on this one. We have at least one customer who is using the en-xa locale to find strings in the UI that are translatable so that they can provide custom translations for their needed locales. With this feature sort of broken, they're having a harder time determining which strings they can translate. I have pointed them to the i18n_extract tool as a stop-gap, but I think this feature is also helpful.

[Bamieh]

Our recommended process to creating custom translation is the following:

1. Extract labels into the en.json file in a custom plugin like this:
   node scripts/i18n_extract --output-dir .\plugins\<custom-plugin>\translations --output-format json

2. Copy the file under the <locale>.json name in the same folder.

3. Apply the translations to the locale file.

4. Update the .i18nrc.json file in custom plugin root to include the translations file path.

5. Verify the file like this:
   node .\scripts\i18n_check.js --fix --include-config .\plugins\<custom-plugin>\.i18nrc.json

The en-xa is used to verify that we have all of our kibana strings internationalized. We are depending less on it internally by improving our checker and tests.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

@Bamieh do you know if that can be closed by the i18n lib bump initiative you've been working on?

[Bamieh]

Context was not propograting correctly in the previous react-intl package and we did not have any code to detect unreachable code. Now i18n throws an error during development if this happens (even in test cases).

So this should be resolved, if we find new issues around we can open a new issue.

We do not have en-xa at the moment since the implementaiton changed after the upgrade and this would need to be introduced again as a feature if we have people requesting it (developers or translators).