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

Re: [XP] Localization

Expand Messages
  • Michael D. Hill
    ... Hah!! I am so busted. I ve been talking a lot with a friend lately about the XP religion problem, so I sent her the letter to gain her reactions. Sorry
    Message 1 of 19 , May 1, 2000
    • 0 Attachment
      At 09:14 AM 5/1/00 -0400, I wrote:
      >(Hellie-- Here's my proposed reply.

      Hah!! I am so busted.

      I've been talking a lot with a friend lately about the XP religion
      problem, so I sent her the letter to gain her reactions.

      Sorry for the odd looking line! Ignore it, please.

      Embarrassedly,
      Hill

      +----------------------------------------------------------+
      |Michael Hill |
      |Software-> Developer, Consultant, Teacher, Coach |
      |Lifeware-> Egghead, Romantic, Grandpa, Communitarian |
      |<uly_REMOVE_THIS_PART_@...> |
      +----------------------------------------------------------+
    • Frank McGeough
      Michael, I think my bias -- developing software that is sold to a whole slew (well, hopefully) set of customers, is showing. I don t develop software for a
      Message 2 of 19 , May 1, 2000
      • 0 Attachment
        Michael,

        I think my bias -- developing software that is sold to a whole slew (well,
        hopefully) set of customers, is showing. I don't develop software for a
        single customer. Perhaps if I did one-off solutions I wouldn't have these
        opinions. Putting myself in those type of shoes I might do things
        differently. If you are achieving long term cost savings and benefits for
        your customers with this technique then I can't argue with you. It will
        probably always just feel wrong to me but I think I understand your point.

        Frank

        >
        > Frank...
        >
        > >In the same sense asking the
        > >customer what docs to produce also troubles me. I don't have trouble
        > >asking the customers for input on "their" doc but I would never
        > >consider asking them -- would you like me to write a database schema
        > >description document so that a support person who doesn't have to be
        > >part of an inner circle can answer your questions?
        >
        > This may feel like the same sense, but certainly the case seems
        > significantly different. Writing that document is *not* like accepting
        > a set of no-brainer coding conventions, but is much more like the
        > burden the original poster felt would derive from a priori localization
        > efforts: It clearly will involve non-trivial cost-to-the-customer.
        > When XP'ers ask the customer to spend money, we do so by asking
        > them to choose stories that spend that money.
        >
        > Why does this seem like a bad thing to do? I know of
        > plenty of customers who'd prefer to pay for docs that are
        > adequate to broad staffing changes at the time they make those
        > changes rather than before. Giving the customer the choice
        > here doesn't seem that strange to me.
      • Kent Quirk
        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
        Message 3 of 19 , May 1, 2000
        • 0 Attachment
          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.

          Background:

          My company develops computer games. After the fall release of our first
          product, I read a little bit about XP online, then grabbed Fowler's book
          on Refactoring and decided to try refactoring and pair programming with
          a complex update we were looking at. It was a wonderful experience. Now
          I'm trying to learn more about it.

          In many ways, XP is really appropriate for building game software. We
          have a small team, and the major requirement is that it be "fun". That's
          hard to figure out in advance. We've always had to be ready to try out
          and then throw out many ideas. Being "done" is basically a matter of
          reaching some critical mass. You want to be functional and playable as
          early as possible, then tune, tune, tune.

          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

          Frank McGeough wrote:
          >
          > Michael,
          >
          > I think my bias -- developing software that is sold to a whole slew (well,
          > hopefully) set of customers, is showing. I don't develop software for a
          > single customer. Perhaps if I did one-off solutions I wouldn't have these
          > opinions. Putting myself in those type of shoes I might do things
          > differently. If you are achieving long term cost savings and benefits for
          > your customers with this technique then I can't argue with you. It will
          > probably always just feel wrong to me but I think I understand your point.
          >
          > Frank
          >
          > >
          > > Frank...
          > >
          > > >In the same sense asking the
          > > >customer what docs to produce also troubles me. I don't have trouble
          > > >asking the customers for input on "their" doc but I would never
          > > >consider asking them -- would you like me to write a database schema
          > > >description document so that a support person who doesn't have to be
          > > >part of an inner circle can answer your questions?
          > >
          > > This may feel like the same sense, but certainly the case seems
          > > significantly different. Writing that document is *not* like accepting
          > > a set of no-brainer coding conventions, but is much more like the
          > > burden the original poster felt would derive from a priori localization
          > > efforts: It clearly will involve non-trivial cost-to-the-customer.
          > > When XP'ers ask the customer to spend money, we do so by asking
          > > them to choose stories that spend that money.
          > >
          > > Why does this seem like a bad thing to do? I know of
          > > plenty of customers who'd prefer to pay for docs that are
          > > adequate to broad staffing changes at the time they make those
          > > changes rather than before. Giving the customer the choice
          > > here doesn't seem that strange to me.

          --
          -----------------------------------------------------------------------
          Kent Quirk | CogniToy: Intelligent toys...
          Game Designer | for intelligent minds.
          kent_quirk@... | http://www.cognitoy.com/
          _____________________________|_________________________________________
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.