Translation of error/exception messages?

[tenzap]

There are a few error messages reported by the library when an NumberParseException is thrown. For example in

libphonenumber-for-php/src/PhoneNumberUtil.php

Lines 1538 to 1543 in f41acc3

	if (!static::isViablePhoneNumber($nationalNumber)) {
	throw new NumberParseException(
	NumberParseException::NOT_A_NUMBER,
	'The string supplied did not seem to be a phone number.'
	);
	}

The labels I identified are:

'The string supplied was too long to parse.'
'The string supplied did not seem to be a phone number.'
'Missing or invalid default region.'
'Could not interpret numbers after plus-sign.'
'The string supplied is too short to be a phone number.'
'The string supplied is too long to be a phone number.'
'The phone-context valid is invalid.'
'Phone number had an IDD, but after this was not long enough to be a viable phone number.'
'Country calling code supplied was not recognised.'

I'm wondering how one could have translations of these and if this would be a good idea. Is it something that would have to be maintained here, or in a supplementary repo, or should each dependent software manage this itself?

[tenzap]

By the way I suspect a typo here: 'The phone-context valid is invalid.' It probably should be 'The phone-context value is invalid.' https://github.com/google/libphonenumber/blob/v9.0.4/cpp/src/phonenumbers/phonenumberutil.cc#L2229

[giggsey]

I've fixed the typo in 9.0.4, thanks for spotting that.

As for translation, I don't really want to do this within the library. Using public constants on the exception class for the strings might be a middle ground solution, allowing users of the library to str_replace if required.

[tenzap]

The constant is already set in the exception, right? Or can some exception constants have different messages?
You suggest to use that constant to determine the message to display, and each client would use this to set its own label, isn't it?

[giggsey]

The existing constant is used for the Exception id/type. I'm proposing adding extra constants for the string instead.

The alternative is introducing more exception types for each error, but I don't like that.

[tenzap]

I don't have any preference and this is not an urgent matter. Maybe at some time someone will jump in to the thread and have any arguments. For now I'll translate based on the current message returned by the exception.

Btw thanks for fixing the typo.