How to set ErrorDocument dynamically for different language

Instead of hardcoding it you should go for the variable based for each region and configure it in region specific virtualhost like 

Hi @girtorapankaj!

Actually, your solution looks quite good to me. If you want it to be more generic, you could replace the regular expressions in the first two lines with something like

SetEnvIfNoCase Request_URI "^/(group|career|[a-z]{2})/([a-z]{2})" MARKET=$1

 If you are able to produce a dispatcher/vhost configuration that does not need additional maintenance/configuration for future languages and markets depends primarily on your content structure. The default, most recommended structure usually has a "/MARKET/LANGUAGE" part in it as per your example. Personally, I always recommend to stick to standard country and language two-letter ISO codes here. That makes a lot of things much easier. In your example, you have some dissenting market identifiers ("group", "career"). While there may be good reasons and totally valid business cases behind that decision it makes things a bit more difficult when it comes to producing generic, low-/non-maintenance configurations. However, if you are able to stick to these two-letter codes in the future a configuration with my example regular expression will work without additional changes.

While the solution that @ritesh_mittal proposed is also another valid approach, I recommend to handle the most basic configurations on dispatcher level. The reason behind that gets a bit clearer if you look not only at the 4xx error code range but also the 5xx HTTP status codes. If your AEM instance is in any kind of trouble (e. g. down or any other error state) and returns a HTTP 500 status it is very likely that it will not be able to actually render a nicely styled error page for that status code and send it to the end user.

My recommendation is:

• Let AEM render your error pages. They can be fully flexible and authored by your content editors, just as normal content pages in AEM.
• Have some kind of ErrorDocument configuration in your dispatcher configuration pointing to these AEM pages. Your example config looks totally fine to me. Please also refer to my adjusted, more generic regular expression for the market/language mapping.
  Please note: your approach is more of an allow list of possible error pages. This is a bit stricter compared to the more generic solution but also requires more maintenance. On the other hand the more generic approach would allow a visitor to request something like "/zz/zz/" and the dispatcher would still try to serve that error page, which would not be the case for your stricter allow list approach. You need to decide where your priority lies.
• If possible, design your content structure to use two-digit country and language ISO codes for market and language.
• Make sure your error pages are/can be cached on the dispatcher. This way they can be server even if your AEM instance is not in a healthy state (as an error code may indicate).
• Bonus: have some kind of script that runs on your dispatcher on a regular basis to pull the error pages from AEM and put them into the dispatcher cache (e. g. cronjob). This way they are always available if you need them.
• As a backup solution you may want to have a static error page outside of the cache directory that is served as a last resort fallback.

Apart from that you may also want to check the ACS AEM Commons Error Page Handler.

Hope that helps!