JSPWiki
  1. JSPWiki
  2. JSPWIKI-143

Unlocalized messages in user management

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.6.0
    • Fix Version/s: 2.9.1
    • Component/s: Localization
    • Labels:
      None

      Description

      When trying to create a new user with an existing name, the page says: 'The login name 'flo' is already taken.'
      I guess it's an Exception from UserManager. It's the same problem with full name (a few lines down).

      Maybe there are the following mesages unlocalized, too:

      JDBCUserDatabase:
      throw new DuplicateUserException( "Cannot rename: the login name '" + newName + "' is already taken." );
      XMLUserDatabase:
      throw ( new DuplicateUserException( "Cannot rename: the login name '" + newName + "' is already taken." ) );

        Issue Links

          Activity

          Hide
          Janne Jalkanen added a comment -

          This is a known issue; these guys have no access to the i18n context... I think this needs a bigger redesign, and I'm not at all sure whether this is the proper pattern.

          Might be better if we adopted a "if you throw an exception, put in the i18n key instead of a textual description" -strategy - but then you can't construct any complicated messages.

          Oh, using varargs would make life a lot easier here.

          Show
          Janne Jalkanen added a comment - This is a known issue; these guys have no access to the i18n context... I think this needs a bigger redesign, and I'm not at all sure whether this is the proper pattern. Might be better if we adopted a "if you throw an exception, put in the i18n key instead of a textual description" -strategy - but then you can't construct any complicated messages. Oh, using varargs would make life a lot easier here.
          Hide
          Janne Jalkanen added a comment -

          Better name.

          Show
          Janne Jalkanen added a comment - Better name.
          Hide
          Andrew Jaquith added a comment -

          The quick fix is pretty easy: just make sure that we initialize the various UserManager classes with a reference to WikiEngine, which would allow us to retrieve the i18n manager and generate a proper message.

          HOWEVER, that's not quite the end of the story. These errors, in particular, are NOT internal errors, but errors that ought to be thrown back to the end-user, and thus need to use the locale of the web user (as opposed to the language of the JVM deployer or runtime). So, it would probably be better to change the exception type to make it simply carry the message key and the name of the user, rather than the error message itself. Web-tier JSPs and classes with access to the user context should, instead, be responsible for creating a locale-specific message.

          I agree that we probably need to re-think this a bit. The general strategy you suggest makes sense.

          The sad thing is that we are going to have to do this in lots more places than just here... It really suggests that we ought to add special constructors to ALL custom JSPWiki Exception types so that they can accept message keys and variable parameters. Yes, varargs would make this MUCH easier...

          Show
          Andrew Jaquith added a comment - The quick fix is pretty easy: just make sure that we initialize the various UserManager classes with a reference to WikiEngine, which would allow us to retrieve the i18n manager and generate a proper message. HOWEVER, that's not quite the end of the story. These errors, in particular, are NOT internal errors, but errors that ought to be thrown back to the end-user, and thus need to use the locale of the web user (as opposed to the language of the JVM deployer or runtime). So, it would probably be better to change the exception type to make it simply carry the message key and the name of the user, rather than the error message itself. Web-tier JSPs and classes with access to the user context should, instead, be responsible for creating a locale-specific message. I agree that we probably need to re-think this a bit. The general strategy you suggest makes sense. The sad thing is that we are going to have to do this in lots more places than just here... It really suggests that we ought to add special constructors to ALL custom JSPWiki Exception types so that they can accept message keys and variable parameters. Yes, varargs would make this MUCH easier...
          Hide
          Janne Jalkanen added a comment -

          The WikiEngine is not enough, you actually need the WikiContext, because that's the only way you can figure out what the current user locale is.

          Which makes things a bit complicated, as it's a real pain to carry the WikiContext everywhere into any API that might have some user-level output.

          One option, is of course, to make WikiContext a ThreadLocal, but that kinda sounds to me like a global variable.

          Putting message keys sounds like a better idea; then have a convenience method in WikiException for getting the localized string. Actually, there's already a Throwable.getLocalizedMessage()...

          Show
          Janne Jalkanen added a comment - The WikiEngine is not enough, you actually need the WikiContext, because that's the only way you can figure out what the current user locale is. Which makes things a bit complicated, as it's a real pain to carry the WikiContext everywhere into any API that might have some user-level output. One option, is of course, to make WikiContext a ThreadLocal, but that kinda sounds to me like a global variable. Putting message keys sounds like a better idea; then have a convenience method in WikiException for getting the localized string. Actually, there's already a Throwable.getLocalizedMessage()...
          Hide
          Janne Jalkanen added a comment -

          Tagging this for 3.0, since we can redo a lot of the APIs anyway.

          Show
          Janne Jalkanen added a comment - Tagging this for 3.0, since we can redo a lot of the APIs anyway.
          Hide
          Juan Pablo Santos Rodríguez added a comment -

          Both UserDatabase receive a WikiEngine instance on their initialize() methods, we could store it to get access to the I18nManager.

          Regarding i18n as a whole (=not only on those classes), another couple of approaches could be used:

          • Transforming InternationalizationManager into an enum, so it can be accesed without a WikiEngine reference, dropping WikiEngine#getInternationalizationManager()
          • Accessing the ResourceBundle directly, as it's done for instance on VariableManager:
          VariableManager.java, lines 484-490
            public String getUsername()
            {
                Principal wup = m_context.getCurrentUser();
          
                ResourceBundle rb = m_context.getBundle( InternationalizationManager.CORE_BUNDLE );
                return wup != null ? wup.getName() : rb.getString( "varmgr.not.logged.in" );
            }
          

          I'm more inclined to using the first approach, though. Thoughts?

          Show
          Juan Pablo Santos Rodríguez added a comment - Both UserDatabase receive a WikiEngine instance on their initialize() methods, we could store it to get access to the I18nManager. Regarding i18n as a whole (=not only on those classes), another couple of approaches could be used: Transforming InternationalizationManager into an enum, so it can be accesed without a WikiEngine reference, dropping WikiEngine#getInternationalizationManager() Accessing the ResourceBundle directly, as it's done for instance on VariableManager: VariableManager.java, lines 484-490 public String getUsername() { Principal wup = m_context.getCurrentUser(); ResourceBundle rb = m_context.getBundle( InternationalizationManager.CORE_BUNDLE ); return wup != null ? wup.getName() : rb.getString( "varmgr.not.logged.in" ); } I'm more inclined to using the first approach, though. Thoughts?
          Hide
          Harry Metske added a comment -

          In any case, you still also need the user's Locale (from WikiContext for example) to get a localized message.
          If you only have access to the I18NManager and not the user's Locale, you can only return messages from the default (English) Bundle.

          Show
          Harry Metske added a comment - In any case, you still also need the user's Locale (from WikiContext for example) to get a localized message. If you only have access to the I18NManager and not the user's Locale, you can only return messages from the default (English) Bundle.
          Hide
          Juan Pablo Santos Rodríguez added a comment -

          fixed in 2.9.1-svn-22

          Show
          Juan Pablo Santos Rodríguez added a comment - fixed in 2.9.1-svn-22

            People

            • Assignee:
              Unassigned
              Reporter:
              Florian Holeczek
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development