Github user ChristopherSchultz commented on the issue: https://github.com/apache/tomcat/pull/137 > 404/403/401.jsp pages in manager and host-manager may benefit from localization, and in that case the lang attribute has to be calculated dynamically to reflect the actual language being used. Though currently those pages are hard-coded with some English text. When introducing i18n for things like this, it's important to know which language was actually chosen when requesting, for example, some unsupported language. The `StringManager` only uses one locale, but it never checks to see which locale it actually got. Client code can't request a string from a particular locale... it can only ask the StringManager which locale it's actually serving. Java's `ResourceBundle` is actually insufficient for implementing real i18n unless every single string is always translated in each resource bundle into each language for which a bundle file exists. When you have non-100% coverage, it's not possible to use just `ResourceBundle` to do the job. Instead, you need a hierarchical system based upon `ResourceBundle` and a few other things. It gets messy. If we just want to use whatever `StringManager` loads on startup, or instantiate a new `StringManager` for each requested-locale and hope that we have 100% string-coverage, we can use that and just put `<html lang="<%= sm.getLocale().getLanguage() %>"` into each file. If we want to provide a better example of implementing i18n in Tomcat, we'll need something more elaborate. I'm +1 on adding `lang="en"` for now since the files are hard-coded in English.
--- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org