List of Console Error messages

[MariusGrunenberg]

Type of issue: (check with "[x]")

• New feature request
• Bug
• Support request
• Documentation

Current behaviour:

When loading the application the console prints out a huge amount of error messages:

https://imgur.com/a/dGJirQi

Expected behavior:

The console should be free of any error messages

Steps to reproduce the issue:

Start the application and look in the console of your browser.

[DenysVuika]

This is related to probing of available translations. For example you may have 3 different translation files:

• en-UK.json
• en-US.json
• en.json

So we probe en-UK, then fallback to en.json for the UK browsers, or en-US -> en.json for US browsers. That also makes more sense for Chinese versions (zh-CN) and pt-BR for example.

What we can do to remove the amount of probing is a separate configuration support where you provide translation mappings yourself, for example:

{
  "locales": {
    "default": "en.json",
    "en-UK": "en.json",
    "en-US": "en.json",
    "zh-CN": "zh-CN.json"
  }
}

In that case the translation service could trust the values and avoid probing.

[MariusGrunenberg]

I don't quite understand. Where does the error happen? What i understand is, there is only one en.json file. And ADF tries to get the en-US.json file, which it won't find. But can't this be intercepted, so there won't be any request at all?

Or wouldn't it be a solution to provide translation files for all of the language versions?

[DenysVuika]

@MariusGrunenberg this is not an error, we check the language and it it's missing, we fallback to the default one. See details on the possible technical solution for ADF in the comments above.

In real life, you should not be expecting your users monitor the browser console output, and you should not expect it to be constantly empty. But if state of the console if the concern, you can help improving the language probing.

[MariusGrunenberg]

What do you mean by missing?

In my view logs should be without errors. Errors should mean something is wrong and an indicator, that there's something which needs to be fixed. If they were warnings it would be ok.

[DenysVuika]

We load translation files only when they are needed, it would be stupid loading everything to the client.

The application does not know how many Chinese or English locales/cultures you support, so it checks the browser culture first and tries to fetch the translation. If the file is not there - it falls back (this was pretty much documented in the past and you can find more details in the docs).
We treat the http error in this case as a signal to keep probing files.

Re own developers and complains - they can help us resolving the issue if that is critical for them

[MariusGrunenberg]

Ok, then I guess a solution, where you can define the standard mappings, would be an easy solution.

[mmcintyre123]

Also in favor of this solution.

This is related to probing of available translations. For example you may have 3 different translation files:

• en-UK.json
• en-US.json
• en.json

So we probe en-UK, then fallback to en.json for the UK browsers, or en-US -> en.json for US browsers. That also makes more sense for Chinese versions (zh-CN) and pt-BR for example.

What we can do to remove the amount of probing is a separate configuration support where you provide translation mappings yourself, for example:

{
  "locales": {
    "default": "en.json",
    "en-UK": "en.json",
    "en-US": "en.json",
    "zh-CN": "zh-CN.json"
  }
}

In that case the translation service could trust the values and avoid probing.

[eromano]

this looks a good idea also to me. Do we have any of you fancy od trying in contribute to it? I am happy to help with it