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

Localization

Expand Messages
  • Jen Wu
    I m kind of intrigued by XP and the benefits that it may bring, but there are a bunch of questions I have about it (more to come). One of them is the idea
    Message 1 of 19 , Apr 27, 2000
      I'm kind of intrigued by XP and the benefits that it may bring, but
      there are a bunch of questions I have about it (more to come). One of
      them is the idea that you should build what you need now, and worry
      about what you might need later. I can see the benefit of this some
      of the time, but what about somethiing like localization? The idea
      that you do what you need to do now and worry about it later is what
      causes programmers to do things like put embedded strings in their
      code. This is a lot faster than breaking stuff out into other files
      (more easily modified by the localization team) later on.

      Making something localization friendly can add a significant burden,
      and it's often unclear when localization will happen (months, maybe
      years later). It's not always clear what locales will be targeted
      (Canada, UK, Australia, France, and Germany seem to be the most common
      for us). Sooner or later, though, localization always becomes an
      issue, and it is almost always painful because people didn't plan for
      it earlier.

      What do people think about this?

      Jen
    • Ron Jeffries
      One thing to consider is to write a localization story and schedule it early. Something like: Make all system messages able to be edited by Marketing before
      Message 2 of 19 , Apr 27, 2000
        One thing to consider is to write a localization story and schedule it
        early. Something like:

        Make all system messages able to be edited by Marketing before release.

        The simplest thing that can possibly work is then to put the messages in a
        file, or in an array somewhere that can be edited and persisted. Since
        you're doing the story early, it's easy and inexpensive.

        If you don't schedule the story early, you're still not lost. In most
        languages, you'll have a few standard objects or routines that handle text
        output anyway. It wouldn't be difficult to change

        printUserMessage( string msg )

        so that it would look up msg in a table based on language and get the
        translation. And it wouldn't be hard to scan the source to find all the
        uses of printUserMessage, either.

        IMO, it's only good design to put the messages SOMEWHERE together, because
        we all know that programmers can't write decent error messages. Once
        they're together, you're most of the way to making localization easy.

        Now ... is there a way to show that having strings all over violates once
        and only once? Maybe you HAVE to refactor them together ...

        Regards,

        At 10:12 AM 4/27/2000 -0700, you wrote:
        >I'm kind of intrigued by XP and the benefits that it may bring, but
        >there are a bunch of questions I have about it (more to come). One of
        >them is the idea that you should build what you need now, and worry
        >about what you might need later. I can see the benefit of this some
        >of the time, but what about somethiing like localization? The idea
        >that you do what you need to do now and worry about it later is what
        >causes programmers to do things like put embedded strings in their
        >code. This is a lot faster than breaking stuff out into other files
        >(more easily modified by the localization team) later on.
        >
        >Making something localization friendly can add a significant burden,
        >and it's often unclear when localization will happen (months, maybe
        >years later). It's not always clear what locales will be targeted
        >(Canada, UK, Australia, France, and Germany seem to be the most common
        >for us). Sooner or later, though, localization always becomes an
        >issue, and it is almost always painful because people didn't plan for
        >it earlier.
        >
        >What do people think about this?
        >
        >Jen
        >
        >
        >To Post a message, send it to: extremeprogramming@...
        >
        >To Unsubscribe, send a blank message to:
        >extremeprogramming-unsubscribe@...
        >
        >Ad-free courtesy of objectmentor.com


        Ron Jeffries
        www.XProgramming.com
      • Michael D. Hill
        ... Jen... This is of course a classic objection to XP s lack of big design in front: For localization (which I usually call internationalization, by the way),
        Message 3 of 19 , Apr 28, 2000
          At 10:12 AM 4/27/00 -0700, Jen wrote:

          >Making something localization friendly can add a significant burden,
          >and it's often unclear when localization will happen (months, maybe
          >years later). It's not always clear what locales will be targeted
          >(Canada, UK, Australia, France, and Germany seem to be the most common
          >for us). Sooner or later, though, localization always becomes an
          >issue, and it is almost always painful because people didn't plan for
          >it earlier.

          Jen...

          This is of course a classic objection to XP's lack of big design in front:
          For localization (which I usually call internationalization, by the way),
          you can
          substitute absolutely any story X where "everyone knows that story X
          will eventually be a part of the system and it'll be a pain to write later".

          The XP response is a nuanced one, consisting of several interlinked ideas:

          1) Story X will be easier to add later than it normally is in other processes:
          The other pieces of the XP process are tightly focused on preparing
          our code for a much higher degree of what I'll call "late-process change".
          Unit Testing and Merciless Refactoring, in particular, will properly drive
          almost all apps away from string literal embeds to other, more readily
          changeable implementations. Flattening the cost of change is a central
          element of the XP process.

          2) There are a thousand story X's, and if we start them all on day one,
          there will never be a ship day. Many more software projects die from
          over-featuring than from under-featuring. Once a steady income can be
          derived from the 'local' market, the international market can be much
          more readily exploited using the incoming cash, especially given item 1.

          3) If customers agree with us that Story X is critical AT AN EARLY
          STAGE, they will push it onto the story stack AT AN EARLY STAGE,
          and once implemented, Story X will be maintained throughout the rest
          of the development. Put internationalization into the list of user stories
          from day one, and encourage your customers to pick it. They'll decide
          for you, and they will be much happier living with the consequences of
          their own decisions than living with the consequences of yours. Even
          if you were right and they were wrong, believe it or not.

          There are lots of arguments against XP that begin with the statement
          that since XP doesn't require developers to implement Story X from
          day one, XP is inherently unsuitable for projects where Story X is
          both a) a must-have for the project and b) a difficult or impossible
          story to add incrementally at a later date.

          One trick to understanding XP's response to these arguments
          is really pretty simple: look at how many such Story X's our
          interlocutors have offered! A scan over the archives here will
          produce a hundred such, and if you mix in OTUG, the Wiki, and
          comp.object, you'll get a thousand or more.

          No process can possibly choose amongst these (often contradictory)
          listings of Story-X candidates. No product could possibly implement
          them all.

          In XP, we let customers produce stories. We implement them in the
          order the customer is interested in seeing them work. We do sometimes
          add stories to the candidate list that the customer didn't think of.
          We even sometimes 'sell' the customer on the worth of a favorite story
          of ours. But we do not implement a story the customer hasn't chosen.
          Ever. No matter how much we might think "They'll thank me later."

          Seeya!
          Hill


          +----------------------------------------------------------+
          |Michael Hill |
          |Software-> Developer, Consultant, Teacher, Coach |
          |Lifeware-> Egghead, Romantic, Grandpa, Communitarian |
          |<uly_REMOVE_THIS_PART_@...> |
          +----------------------------------------------------------+
        • Frank McGeough
          Although I appreciate the patient s bill of rights sort of approach that xp takes to the customer, I have a problem with letting the patient pick his
          Message 4 of 19 , Apr 29, 2000
            Although I appreciate the 'patient's bill of rights' sort of approach
            that xp takes to the customer, I have a problem with letting the
            patient pick his treatment in some cases. If there are two treatments
            that are basically equal then I want the options and risks associated
            with each presented to me and I'd like to choose. What I don't want is
            for something essential to be offered up as a choice. If I'm having an
            operation that requires the use of antibiotics I want the doctor to
            say here's what is effective infection prevention based on my
            knowledge and experience. I don't want them to say well what do you
            think? Do you want to do infection management or not? I would also
            expect them to walk away from a patient who is suggesting a treatment
            course that is patently dangerous or neglectful.

            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.
            Why is it offered up to the customer as a choice? Why not adopt the
            coding standards in the first place? 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? 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 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.


            ----- Original Message -----
            From: "Michael D. Hill" <uly@...>

            > This is of course a classic objection to XP's lack of big design in
            front:
            > For localization (which I usually call internationalization, by the
            way),
            > you can
            > substitute absolutely any story X where "everyone knows that story X
            > will eventually be a part of the system and it'll be a pain to write
            later".
            > <snip>
            > In XP, we let customers produce stories. We implement them in the
            > order the customer is interested in seeing them work. We do
            sometimes
            > add stories to the candidate list that the customer didn't think of.
            > We even sometimes 'sell' the customer on the worth of a favorite
            story
            > of ours. But we do not implement a story the customer hasn't
            chosen.
            > Ever. No matter how much we might think "They'll thank me later."
          • 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 5 of 19 , May 1, 2000
              (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 6 of 19 , May 1, 2000
                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 7 of 19 , May 1, 2000
                  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 8 of 19 , May 1, 2000
                    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 9 of 19 , May 1, 2000
                      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 10 of 19 , May 1, 2000
                        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 11 of 19 , May 1, 2000
                          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 12 of 19 , May 1, 2000
                            > > 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 13 of 19 , May 1, 2000
                              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 14 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 15 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 16 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 17 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 18 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 19 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.