Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Localization

Expand Messages
  • Andy Glew
    ... Another quibble: I may only use one version, but that is IMHO a design defect. I d like to have access to many of the disparate internationalization
    Message 1 of 19 , May 1 1:58 PM
      > > So...any thoughts on how you interact with the "customer" over issues
      > > like internationalization, and portability? Any individual customer
      > > doesn't care about either issue -- they only use one version.

      Another quibble: I may only use one version, but that is
      IMHO a design defect. I'd like to have access to many of
      the disparate internationalization features of UK, US and
      Canadian English, Quebecois and European French,
      Japanese and Chinese, but so many "internationalized"
      packages make it awkward to handle them all at the same
      time.
    • Jen Wu
      My conclusion from the discussion is that localization isn t something decided by XP -- it s decided by the team. I guess a team that s more aware of past
      Message 2 of 19 , May 1 7:19 PM
        My conclusion from the discussion is that localization isn't something
        decided by XP -- it's decided by the team. I guess a team that's more
        aware of past history and what customers are likely to require is likely
        to make a good decision. I'm sure sometimes this will lead to building
        in localization early, sometimes it won't ... I guess I originally read
        XP to be less flexible, to suggest that you defer the effort until
        later.

        In our case, everyone on the team believes localization is important
        from the get go, so it looks like it's going in!

        Jen
      • Mike Bowler
        ... I realize that we ve strayed off topic here but this code is walking into a common localization trap. Localization should NEVER be done at the point that
        Message 3 of 19 , Aug 22, 2001
          >> Seems to me, you've *increased* the pain compared to implementing
          >> formatMessage. Instead of a single-line call, you've now got an
          >> entire class, complete with constructor, and you've moved the
          >> message from one
          >
          >Perhaps you don't need a class for each exception; how about an
          >exception factory, you can do this:
          >
          >throw new ExceptionFactory.fileProblem(fileName)
          >
          >Then all of your formatting is in one place (easy to
          >internationalize).

          I realize that we've strayed off topic here but this code is walking into a common
          localization trap. Localization should NEVER be done at the point that you are
          throwing the exception. It should be done just before the information is displayed to
          the user.

          You aren't guarenteed to know the locale at the point the error occurs so you cannot
          do localization at that point. The error could have happened on a different machine
          than the one that displays the error message. Or the user interface could support
          on-the-fly local changes and the locale could have changed several times before the
          error message is displayed.

          Every application that I write is delivered in at least two languages (English and
          French) so internationalization/localization is always one of my early stories. :-)


          --
          Mike Bowler
          Principal, Gargoyle Software Inc.
          Voice: (416) 822-0973 | Email : mbowler@...
          Fax : (416) 822-0975 | Website: http://www.GargoyleSoftware.com
        • Kerns, Bob
          Not guaranteed to know the locale? FIX IT! I don t see why you say that only the UI could support on-the-fly locale changes, and I especially don t see why
          Message 4 of 19 , Aug 23, 2001
            Not guaranteed to know the locale? FIX IT!

            I don't see why you say that only the UI could support on-the-fly locale
            changes, and I especially don't see why you say the locale could have
            changed several times before the error message is displayed.

            While I can construct scenarios for this (such as logging with a GUI for
            formatting the log later, ala NT event log), it seems like a MAJOR
            overgeneralization to make these statements, which in my experience, are
            rarely required to be true, even in distributed apps.

            In fact, in distributed apps, you frequently do not have access to the
            unformatted information (depending on how the underlying technology passes
            error information around), so often ensuring the remote side knows the
            current locale for the session is the only way to go. (Yes, I do regard this
            as a defect in said technologies!)

            But I absolutely agree that the message has to be formatted in a
            locale-aware place! But Exceptions are no exception here -- ANY place that
            supplies textual information must be locale aware.

            Please note that I am not arguing AGAINST separating the presentation of the
            error from collecting the information. After all, we follow that principal
            for most other forms of information.

            However:
            1) Most of the code that you use that you didn't write, doesn't work this
            way. Providing locale information allows it to work.
            2) They mechanisms to accomplish this definitely do NOT exist
            out-of-the-box; you'll have to create them, and this may be especially
            problematic for servers of distributed information.
            3) It significantly complicates the code, as you now need an exception class
            for every distinct message.

            #1 is a real pain. Take Java for example: Sun not only doesn't follow your
            dictates -- Sun doesn't even PERMIT localization of exceptions they throw.
            The runtime is full of hard-coded messages that intermix the information
            (data) with the text. For example, FileNotFoundException accepts the path to
            the file as one argument, and the reason as another -- but then promptly
            combines them into a formatted string and passes it to the caller,
            discarding the path.

            The workaround for #1 is to track the relevant information (such as
            filename), catch their exception and throw your own. Unfortunately, you
            don't always have any way to tell what the relevant information was at the
            point the exception was thrown, so your message may be necessarily less
            informative than the original, unless you're into parsing error messages to
            extract information!!

            A workaround for #3 is to make formatMessage return a FormattedMessage
            object, containing the ID of the message and an array of parameters. You
            then need to subclass every type of exception you'll throw, to take a
            FormattedMessage object. So this isn't free, but it's a lot cheaper than a
            subclass for every contained message.

            You will note that my original code (based on OAOO) is compatible with this
            approach, but doesn't require you to implement it unless its needed (YAGNI).
            If you always throw your own exception classes, you don't even have to
            revisit the calling sites -- just change formatMessage, and change the
            constructors on your exception classes!

            --- Original Message ---
            Date: Wed, 22 Aug 2001 20:27:20 -0500
            From: Mike Bowler <mbowler@...>
            Subject: Localization
            I realize that we've strayed off topic here but this code is walking into a
            common
            localization trap. Localization should NEVER be done at the point that you
            are
            throwing the exception. It should be done just before the information is
            displayed to
            the user.

            You aren't guarenteed to know the locale at the point the error occurs so
            you cannot
            do localization at that point. The error could have happened on a different
            machine
            than the one that displays the error message. Or the user interface could
            support
            on-the-fly local changes and the locale could have changed several times
            before the
            error message is displayed.
          • Ron Jeffries
            ... Error occurs on our server in Latvia and passes through our main database in Tanzania before being reported to our sysop in Bolivia. Ron Jeffries
            Message 5 of 19 , Aug 23, 2001
              Responding to Kerns, Bob (08:56 AM 8/23/2001 -0500):
              >I don't see why you say that only the UI could support on-the-fly locale
              >changes, and I especially don't see why you say the locale could have
              >changed several times before the error message is displayed.

              Error occurs on our server in Latvia and passes through our main database
              in Tanzania before being reported to our sysop in Bolivia.

              Ron Jeffries
              www.XProgramming.com
              The practices are not the knowing. They are a path to the knowing.
            • Mike Bowler
              ... Say we have an app that supports on-the-fly locale changes between English and French (almost all the apps I write). While the locale is set to English,
              Message 6 of 19 , Aug 23, 2001
                >> Or the user interface could support on-the-fly local
                >> changes and the locale could have changed several
                >> times before the error message is displayed.
                >
                > I don't see why you say that only the UI could support
                > on-the-fly locale changes, and I especially don't see
                > why you say the locale could have changed several
                > times before the error message is displayed.

                Say we have an app that supports on-the-fly locale changes between English and French
                (almost all the apps I write). While the locale is set to English, an error occurs and
                we display the error message. Now the user switches to French (we can do on-the-fly
                changes here, right?) and the error also changes into French. We couldn't have done
                that if we had localized at the time that the error occurred. We have to wait until
                the text is about to be displayed before localizing.

                If the error hadn't been displayed immediately or if it was logged on a different
                machine then the locale could have changed before the message is displayed for the
                first time

                > Not guaranteed to know the locale? FIX IT!

                Given the scenario above, I don't know how.

                If you perform localization at the point the error occurs then how do you resolve this
                problem?

                --
                Mike Bowler
                Principal, Gargoyle Software Inc.
                Voice: (416) 822-0973 | Email : mbowler@...
                Fax : (416) 822-0975 | Website: http://www.GargoyleSoftware.com
              • Adam Judson
                ... walking into a common ... that you are ... information is displayed to ... I d say something even stronger. The text of an error message, even if we only
                Message 7 of 19 , Aug 23, 2001
                  --- In extremeprogramming@y..., Mike Bowler <mbowler@g...> wrote:
                  > I realize that we've strayed off topic here but this code is
                  walking into a common
                  > localization trap. Localization should NEVER be done at the point
                  that you are
                  > throwing the exception. It should be done just before the
                  information is displayed to
                  > the user.
                  >

                  I'd say something even stronger. The text of an error message,
                  even if we only ever have one language, should NEVER be determined
                  at the point you throw an exception. It should be determined when
                  the information is displayed to the user. User messages are related
                  to the context in which they are running. The classes reporting
                  error conditions don't know this. Often these classes don't even
                  know if the error condition is even an error as far as the user is
                  concerned.

                  The only time it makes sense to hard code text is when it is info that
                  won't be seen by the user.

                  e.g. data gets written to a log file.
                  In this case, I'm the one who will have to look at the log file, so
                  the text better be in English. Hmmm, this example breaks down if you
                  have support staff in different countries who need to read the log
                  file I guess.

                  In either case, exceptions and error codes from various parts of the
                  code are NOT the same thing as messages we display to the users of
                  our code. There is a mapping from errors to messages, but only the
                  application should know what this is.

                  Adam.
                  (who also works in Toronto, so has to deliver app's that can toggle
                  between English and French at places where the user clearly should
                  have already decided what language they want to use.)
                • kyle@kylecordes.com
                  ... walking into a common ... that you are You are right, of course. My intention was to demonstrate that a method might do (rather than an entire class), not
                  Message 8 of 19 , Aug 23, 2001
                    --- In extremeprogramming@y..., Mike Bowler <mbowler@g...> wrote:
                    > >Perhaps you don't need a class for each exception; how about an
                    > >exception factory, you can do this:
                    > >
                    > >throw new ExceptionFactory.fileProblem(fileName)
                    > >
                    > >Then all of your formatting is in one place (easy to
                    > >internationalize).

                    > I realize that we've strayed off topic here but this code is
                    walking into a common
                    > localization trap. Localization should NEVER be done at the point
                    that you are

                    You are right, of course. My intention was to demonstrate that a
                    method might do (rather than an entire class), not to suggest a
                    (poor) i18n / l10n technique.

                    For that matter, my code fragment was incorrect. I meant this:

                    throw ExceptionFactory.fileProblem(fileName)


                    Kyle Cordes
                    www.kylecordes.com
                  Your message has been successfully submitted and would be delivered to recipients shortly.