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

Re: [XP] Localization

Expand Messages
  • Michael D. Hill
    (Hellie-- Here s my proposed reply.) Frank... ... You and the original poster differ in your opinion on the difficulty. If it s easy, natural, and correct
    Message 1 of 19 , May 1, 2000
    • 0 Attachment
      (Hellie-- Here's my proposed reply.)

      Frank...

      > This is the crux of my problem with some of the postings that I see
      > regarding xp. I see a sham naivete. In the example below, if you've
      > done an internationalized system then you know it requires no real
      > additional work but simply a commitment to a set of coding practices.

      I cite the original post here:

      >>Making something localization friendly can add a significant burden,
      >>and it's often unclear when localization will happen (months, maybe
      >>years later).

      You and the original poster differ in your opinion on the
      difficulty.

      If it's easy, natural, and correct coding style, you'll discover it
      naturally during the refactoring, (point 1 in my first reply).
      If it's hard, unnatural, and a burden, then you put it into the
      story pile and your customer will choose when to implement it
      (point 3 in my first reply).

      >Why is it offered up to the customer as a choice?

      Because the original poster thought it was a user story, where you
      don't think it's a story at all, just an item in the coding standard.

      > Why not adopt the coding standards in the first place?

      If it's as relatively free as, say, a system of names, then go for it.
      XP does not require any particular coding standard, it only requires
      that the development team adopt one.

      >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.

      >Would you like me
      >to write a description and example code for my completion port class
      >library so when the company decides to transition the whole project
      >away from the inner circle to a support team in India that they are
      >not totally at sea?

      I might *really* answer this question with 'No.', and it might
      *really* be the best business decision. (As an aside, don't forget that
      the unit tests provide extensive example code and a form of viable
      documentation. That's a side issue to your real question, but it's worth
      mentioning.)

      >I do it because I already know it's intrinsic
      >goodness and the practicality of doing so from 15 (or so) years of my
      >own experience and my successes and failures.

      This is certainly the issue. The idea that's present in the
      original post and in your response is the idea that there
      are some stories that are so inherently valuable in all projects
      that we *must* implement them, whether or not the customer
      chooses them.

      (An aside: The doctor metaphor is frequently used in this
      argument. I wish I felt that doctors were in more fundamental
      consensus about good treatment than they really are. In my
      personal experience they are even more contentious than
      developers!)

      As for sham naivete, it just isn't there. XP isn't *pretending*
      to know less than our customer. Divide the world of knowledge
      into three areas:

      1) Things we know for sure about development. XP embeds these
      directly in the values and practices.

      2) Things we don't know about customer business. XP requires
      the customer to select user stories as a way of spending money
      on these.

      3) Everything else, including things we *think* about the customer's
      business and things we *think* about development. XP (conservatively)
      treats all of these as though they were category 2, especially if they
      involve costs to the customer.

      We may be wrong. Maybe we haven't finalized category 1. Maybe
      in the fullness of time some things will move from category 3 to 1.
      But localization (the hard version) doesn't seem a likely candidate, and
      localization (the easy version) is already there via coding convention.
      External documentation doesn't seem like it will ever be in category 1.

      I reiterate, in twenty years of independent contracting and
      consultation I have seen MANY projects fail because over-
      featuring prevented a team from developing anything at all.
      I have never seen even one fail because it was not localization-
      capable at the first release.

      Sincerely,
      Hill
      +----------------------------------------------------------+
      |Michael Hill |
      |Software-> Developer, Consultant, Teacher, Coach |
      |Lifeware-> Egghead, Romantic, Grandpa, Communitarian |
      |<uly_REMOVE_THIS_PART_@...> |
      +----------------------------------------------------------+
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.