Add a test locale

[atjn]

I think it would be useful to have a test locale for when you want to make sure your app can support all locales, even those with very long strings. Right now, you have to guess how much space to give each string, and that is a tedious and error prone method.

The length of each string in the test locale is as long as it is allowed to be, according to these limits:

String	Max characters
decimal point	1
thousands sep	1
speed	4
distance	3
temperature	2
am/pm	3
short time	5
long time	8
short date	11
long date	14
short month	4
long month	11
short day	4
long day	13

If @gfwilliams agrees with these limits, I think it could be useful to document them somewhere, and also add some code to verify that they are being followed.

The limits support all existing locales, except a few that have unnecessarily long strings that you cannot expect a small watch to display. I have checked each case, and it is possible to make those strings shorter.

Character count is not the only issue though. The width and height of the characters can also have a big impact on the visual size of the string. I have made sure to use tall and wide characters such that the test strings are at least as big as the biggest real locale strings.

I have tested a bunch of apps with the test locale, and most support it, so I think it is a good middle ground that is not too restrictive on the string lengths, but also doesn't require apps to use too much screen space.

[gfwilliams]

Thanks, this sounds good. Although just scanning I feel like long day/month might be a bit on the high side?

As you say it would be good to have a test. We do have a sanity test that runs when the locale html file is run:

BangleApps/apps/locale/locale.html

Lines 102 to 125 in 4631edc

	// do some sanity checks
	Object.keys(locales).forEach(function(localeName) {
	var locale = locales[localeName];
	if (locale.trans && !locale.trans.on) console.error(localeName+": If translations are provided, 'on' *must* be included");
	if (distanceUnits[locale.distance[0]]===undefined) console.error(localeName+": Unknown distance unit "+locale.distance[0]);
	if (distanceUnits[locale.distance[1]]===undefined) console.error(localeName+": Unknown distance unit "+locale.distance[1]);
	if (speedUnits[locale.speed]===undefined) console.error(localeName+": Unknown speed unit "+locale.speed);
	if (locale.temperature!='°C' && locale.temperature!='°F')
	console.error(localeName+": Unknown temperature unit "+locale.temperature);
	// Now check that codepage is ok and all chars in translation are in that codepage
	const codePageName = "ISO8859-1";
	if (locale.codePage) codePageName = locale.codePage;
	const codePage = codePages[codePageName];
	if (codePage===undefined) console.error(localeName+": Unknown codePage "+codePageName);
	function checkChars(v,path) {
	if ("object"==typeof v)
	Object.keys(v).forEach(k=>checkChars(v[k], path+"."+k));
	else if ("string"==typeof v)
	for (var i=0;i<v.length;i++)
	if (codePageLookup(localeName, codePage, v[i])===undefined)
	console.error(` ... in ${path}[${i}]`);
	}
	checkChars(locale,localeName);
	});

It might be good to have the checks in there, and maybe an explicit MAX_LENGTHS = { ... } right at the top of locales.js?

[atjn]

Although just scanning I feel like long day/month might be a bit on the high side?

Those limits are set by the longest real month and date. I don't remember which language it was, but I can find it if you want me to.

Obviously you could just set a shorter limit and thereby force a few languages to concatenate the names, but I'm not convinced that it would be a good solution. You'd be removing information that apps might want to use, and if they want something longer than the abbreviated name, but shorter than the full name, they can just cut the name at an arbitrary length.

It might be good to have the checks in there, and maybe an explicit MAX_LENGTHS = { ... } right at the top of locales.js?

Yeah, I was thinking the same.

[gfwilliams]

Ok, sounds good - as you say as long as the short version is actually short, that should probably do

[atjn]

@gfwilliams I would actually want to move the sanity check out of the html file and into a separate script. This would allow the check to run as a Github action that can catch mistakes before they are merged. You have also mentioned that you want the app loader to be as light on resources as possible because it is used on budget phones, so it would make sense to not run the same sanity check over and over on every single phone for every single locale.

Do you agree?

[gfwilliams]

Ok, yes, that's fine. I think realistically the sanity check is pretty minimal and only runs when loading the locale app, so it's not a big deal - but running as a github action would negate the need for it (maybe just do it from the sanitycheck script to avoid having to modify github actions as well as npm test)

[atjn]

@gfwilliams now that we added a formal linter, I think this is ready to be merged?

One thing to note: I chose to use the french 'h' in this locale, because I wanted to make the time strings as wide as possible. I don't think there is anything wrong with adding it to a test locale, it will probably just nudge app owners to implement some workaround for uncommon formats, which I think is good. But if you think it should not be in here, I can get rid of it.

[gfwilliams]

Looks good, thanks! As you say I'm unsure about the 'h' but hopefully it's not a big deal unless someone starts just filing hundreds of issues against existing clocks without offering fixes :)