Translating Errors in other languages

[amitguptagwl]

Hi All,

As a next step, and suggested by @NorbertHuethmayr we're planning to return error message in different languages. We have not thought about how many languages. But we need your opinion and support to translate them in different languages.

Here is the list of error messages that we currently show in validators;

Code

InvalidXml
InvalidChar
InvalidTag
InvalidAttr

Messages

"There is an unnecessary space between tag name and backward slash '</ ..'."
"Tag '"+tagName+"' is an invalid name."
"Attributes for '"+tagName+"' have open quote."
"Closing tag '"+tagName+"' doesn't have proper closing."
"Closing tag '"+tagName+"' can't have attributes or invalid starting."
"Closing tag '"+otg+"' is expected inplace of '"+tagName+"'."
'Multiple possible root nodes found.'
"char '&' is not expected."
"char '"+xmlData[i]+"' is not expected."
'Start tag expected.'
"Invalid '"+tags+"' found."
'XML declaration allowed only at the start of the document.'
"Attribute '"+attrName+"' has no space in starting."
"boolean attribute '"+attrName+"' is not allowed."
"Attribute '"+attrName+"' is an invalid name."
"Attribute '"+attrName+"' is repeated."

[sverweij]

Internationalisation is hairy. One thing you might find a need for with the current set of labels is offering translators more flexibility where to place the variables. Target language's grammars will dictate the variables to be in different spots - or the strings before and after the attributes be swapped entirely

For example: Closing tag 'unclosed' doesn't have proper closing. Might very well translate into Onfatsoenlijke afsluiting voor afsluitetiket 'unclosed'. - which will be hard to do with a string-concatenation setup.

There's more wormholes to disappear in with i18n - might be useful to look into a library, depending on your ambition level.
Example: Although your current labels do not seem to affected with pluralisation, you will run into it at some point. In English you typically put an s behind a word and be done with it. At least in some Slavic languages the postfix or the complete shape of the word depends on the amount you're talking about - the translation of seats in {number} seats will look different depending on whether it's 2, 10, 20, 23 or 30 of them ...

I have no suggestions for libraries that are suitable for fast-xml-parser, but for reference - Angular's ngx-translate got a lot of i18n things right.

[nhuethmayr]

Hi,

my idea was to use a dictionary-style approach. The key represents a certain message while the text for the user (incl. placeholders for dynamic values) can be found in the dictionaries value.

That way every language can have its dictionary with the proper text, no matter the format.

That would not solve 100% of all the combinations but I think it can be considered good enough.

BR
Norbert

[amitguptagwl]

@NorbertHuethmayr I even thought about that. But it depends on how user wants to use it.

[pumano]

any news on this?