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

RE: [XP] Localization

Expand Messages
  • Swatosh, Joe R NWP
    ... Okay, I ll take a stab at this one. In terms of XP s roles, all those many customers with their many different, conflicting needs, are represented by a
    Message 1 of 19 , May 1, 2000
    • 0 Attachment
      RE: [XP] Localization

      > -----Original Message-----
      > From: Kent Quirk [mailto:kent_quirk@...]
      > Sent: Monday, May 01, 2000 07:53
      > To: extremeprogramming@egroups.com
      > Subject: Re: [XP] Localization
      >
      >
      > I'd be interested in hearing more on the topic of developing
      > mass-market
      > software, where any individual customer will have a wide variety of
      > interests and needs, but you have to develop software that meets the
      > needs of a variety of customers in order to be worth developing.
      >

      Okay, I'll take a stab at this one.  In terms of XP's roles, all those many customers with their many different, conflicting needs, are represented by a single entity that fulfills the customer role.  My recollection is that Kent Beck calls this entity the "Marketing Department."  So it's their job to distill all the conflicting requirements into a coherent set of User Stories for the developers.

      Speaking from no experience, just parroting the book and XpImmersionTwo.

      Joe Swatosh                | mailto:Joe.R.Swatosh@...
      nLink contract employee    | mailto:jswatosh@...
      US Army Corps of Engineers | Northwestern Division, Portland District
      CENWP-HDC-P                | Hydroelectric Design Center
      220 NW 8th Ave             | v:(503) 808-4032
      Portland, OR 97209         | f:(503) 808-4029

    • Frank McGeough
      A small quibble. A lot of companies are international. If you sell them your product they will want it to be able to run equally as well in all the countries
      Message 2 of 19 , May 1, 2000
      • 0 Attachment
        A small quibble. A lot of companies are international. If you sell them your
        product they will want it to be able to run equally as well in all the
        countries they are in. They make their purchase decision with that in mind.
        Indeed you may find that large customers run different versions of your
        product because the upgrade process is done according to timing that is
        different in different countries due to scheduled business meetings or
        whatever.

        ----- Original Message -----
        From: Kent Quirk <kent_quirk@...>
        To: <extremeprogramming@egroups.com>
        Sent: Monday, May 01, 2000 10:53 AM
        Subject: Re: [XP] Localization


        > 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.
        >
        > Kent
      • Lynn, James
        Okay, I ll take a stab at this one. In terms of XP s roles, all those many customers with their many different, conflicting needs, are represented by a single
        Message 3 of 19 , May 1, 2000
        • 0 Attachment
          RE: [XP] Localization

          Okay, I'll take a stab at this one.  In terms of XP's roles, all those many customers with their many different, conflicting needs, are represented by a single entity that fulfills the customer role.  My recollection is that Kent Beck calls this entity the "Marketing Department."  So it's their job to distill all the conflicting requirements into a coherent set of User Stories for the developers. 

          This is in fact what I thought the role of marketing involves: finding out what the market wants. It does not matter whether you use XP or not. In the case of XP, I view them as the customer, as they are supposed to know the almalgamation of all the things the customer wants.

          James Lynn

        • 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 4 of 19 , May 1, 2000
          • 0 Attachment
            > > 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 5 of 19 , May 1, 2000
            • 0 Attachment
              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 6 of 19 , Aug 22, 2001
              • 0 Attachment
                >> 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 7 of 19 , Aug 23, 2001
                • 0 Attachment
                  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 8 of 19 , Aug 23, 2001
                  • 0 Attachment
                    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 9 of 19 , Aug 23, 2001
                    • 0 Attachment
                      >> 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 10 of 19 , Aug 23, 2001
                      • 0 Attachment
                        --- 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 11 of 19 , Aug 23, 2001
                        • 0 Attachment
                          --- 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.