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

Reply via email to