Skip to content

Localization support #6

Open
Open
Localization support#6

Description

@TheE
TheE
opened on Feb 24, 2015

Intake should provide some sort of support for localizations. This affects two fields:

  1. Internal localization: All hard-coded strings should be externalized in a Java ResourceBundle and some behaviour might need to be updated in order to work as expected in an localized environment. Some points might need discussion:
    • Intake has several internal runtime exceptions that the end-user should never see (e.g. ParametricException). These might not need localization.
    • It might be a good idea to allow users to alter or replace the internal localization logic by providing custom translations. In that case the two entry points are ParametricBuilder and CommandGraph.
  2. External localization: The values in command annotations, specifically description and help, need localization support. The entry point here is the ParametricBuilder.
    • If localizations use key -> value relationships, as enforced by Java resource bundles, description and help methods would need to return the key. This contradicts the current behaviour where both methods return the actual value, so a support for that old, non localised behaviour is needed.

On both fields, the support should be as flexible as possible and do not enforce any specific way of handling Locales on the user.

Since I need localization support in MyWarp, I have implemented a limited localization support in my own Intake fork (i18n branch). I would be happy to contribute these changes in a PR so there is something to discuss about, if the general direction fits.

Activity

  1. onbjerg commented on Aug 7, 2015

    @onbjerg
    onbjerg
    on Aug 7, 2015
    Contributor

    👍 Your branch seems to be behind the Intake master branch, though.

  2. TheE commented on Aug 7, 2015

    @TheE
    TheE
    on Aug 7, 2015
    Author

    My branch is still on version 3 as I have not (yet) been able to update it and depending projects.

    I am still interested in contributing localization support to Intake 4.

  3. sk89q commented on Aug 14, 2015

    @sk89q
    sk89q
    on Aug 14, 2015
    Member

    One reason why I haven't gotten around to localization is because I was hoping to make localization per-player, especially since the client send its language setting. However, realistically I don't know how many people care about that.

  4. onbjerg commented on Aug 14, 2015

    @onbjerg
    onbjerg
    on Aug 14, 2015
    Contributor

    That sounds like a nice idea.

  5. ewized commented on Aug 14, 2015

    @ewized
    ewized
    on Aug 14, 2015

    I care about that.

    On Fri, Aug 14, 2015 at 12:10 AM マルウェア notifications@github.com wrote:

    That sounds like a nice idea.

    —
    Reply to this email directly or view it on GitHub
    #6 (comment).

  6. sk89q commented on Aug 14, 2015

    @sk89q
    sk89q
    on Aug 14, 2015
    Member

    Then the other issue is that there isn't really some localization project I'm aware of that's really suited for it (other than ones in Java web frameworks) so that would mean having some resource loading library specific to Intake, while the rest of your project might use something else. Unless, of course, I make a separate localization lib but I haven't really gotten around to that.

  7. TheE commented on Sep 2, 2015

    @TheE
    TheE
    on Sep 2, 2015
    Author

    Why not use Java's RessourceBundles? A RessourceBundle implementation can be used without using Java's lookup process (static RessourceBundle.getBundle(String) methods). An even if this lookup process is used, it is completely configurable by using a custom RessourceBundle.Control implementation.

    What exactly did you have in mind for per-player localizations? I would have thought that an RessourceProvidersuch as

    public interface ResourceProvider {

    /**
     * Gets a ResourceBundle that contains the localised strings applicable in the
     * context it is called.
     *
     * @return the ResourceBundle
     * @throws java.util.MissingResourceException if such a ResourceBundle does
     * not exist
     */
    ResourceBundle getBundle();

}

    is sufficient as it is left to the user to resolve the currently applicable RessourceBundle (e.g. in MyWarp, I use a ThreadLocal object to keep track of the current user's Locale).
    If that is not applicable, the interface could probably get access to the current CommandContext or even a custom context object to wrap other dependencies.

  8. sk89q commented on Sep 2, 2015

    @sk89q
    sk89q
    on Sep 2, 2015
    Member

    It forces a ThreadLocal upon the user, although I suppose it's not a big issue.

    I suppose the other reason why i haven't gotten around to it is because I haven't added localization to WE yet.

  9. TheE commented on Feb 15, 2016

    @TheE
    TheE
    on Feb 15, 2016
    Author

    I just updated my fork for version 4 of Intake.

    Compared with my previous fork, I changed the approach:

    • Command annotations can be localize by specifying keys in the annotations that are resolved by a custom resolver the client registered with the ParametricBuilder.
    • Internal exception messages are not natively localized (as in my fork of version 3). The client is expected to catch all possible exceptions and localize them as desired.However to do so, some internal changes where needed:
      1. Each exception needs to have a single, well defined reason to be thrown (e.g. unqualified usage of InvalidUsageExceptions for missing or wrong sub-commands can no longer be accepted). I added several additional Exceptions for such cases;
      2. Currently the AbstractParametricCallable wraps lots of internal exceptions with InvalidUsageException, the original cause is hidden behind the getCause() method. Since this makes parsing the exceptions a two step-process (catch InvalidUsageException and parse cause) witch is hard to maintain for larger setups, I replaced this wrapping with a DefaultExceptionHandler that can be replaced by clients.
      3. ExceptionHandlers can request an ExceptionContext that contains contextual information that can be used for parsing.
      4. Although unrelated, all public constructors of CommandContext have been deprecated because I suspect the Builder should be used.

    There is also a new example for internationalized commands.

    @sk89q any chance to get these changes into the master version?
    (I suspect that especially (ii.) and (iii.) could be solved differently by requiring callers to use the getCause()method, perhaps sourcing a dedicated ExceptionHandleras I do for parsing ArgumentExceptions in the example. This might be worth to discuss if you are interested in pulling these changes into master.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions