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
