Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Design iSeries Applications with Translation in Mind

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Design iSeries Applications with Translation in Mind

    ** This thread discusses the article: Design iSeries Applications with Translation in Mind **
    ** This thread discusses the Content article: Design iSeries Applications with Translation in Mind **
    0

  • #2
    Design iSeries Applications with Translation in Mind

    ** This thread discusses the article: Design iSeries Applications with Translation in Mind **
    As the author of "Design iSeries Applications with Translation in Mind", I welcome any questions, comments or suggestions (good or bad) that you may have. Best regards, John Greenwood.

    Comment


    • #3
      Design iSeries Applications with Translation in Mind

      ** This thread discusses the article: Design iSeries Applications with Translation in Mind **
      I have worked with a system that did the "all literal text comes from a message file" thing. My concept always was that this was done to support foreign language versions, which did indeed exist for this product. The thing that I noted was that this made the system much more difficult to maintain and modify. As analysts working on a 3rd party system, we frequently use literal text as guideposts in the code. In other words, if we've found the literals from a screen or report, we've found the correct code. Now this can be overcome with documentation. However, this system was rather well documented by most application standards. Furthermore, this is a deeply technical issue (being code navigation) and that is where documentation is generally weakest. I suspect that most vendors believe that if you want to mess around at this level, then you have picked your own poison and simply have to make the best of it. It's just not their problem. My broader point is that this seems to me to be a level of code abstraction. There are other types of abstraction possible too. One example is the ability to support multiple databases (DB2, Oracle, Sybase, MySQL, etc.). Another example is the ability of code to be portable to multiple operating systems. I have long suspected that higher abstraction levels result in code that is more powerful, but also more difficult to understand. On a down-to-earth note, my experience with clients often goes something like this: Client: I want another field to display here. Analyst: Sorry, there isn't enough room for that data element. Client: Sure there is, I'll prove it to you with my ruler... Analyst: No, that room only appears to be available. It's reserved for the expansion caused by foreign language translations. Client: But I don't speak another language, and our system is configured for English! Analyst: I can't make the change you're asking for. It will undermine the entire system's design. Client: I just don't understand. It's right there, and it would be easy... It's not a happy situation. The Client is asking for a tactical change that will help them and their business. The Analyst is declining on the basis of architectural issues, which seem remote and, well, abstract to the Client.

      Comment


      • #4
        Design iSeries Applications with Translation in Mind

        ** This thread discusses the article: Design iSeries Applications with Translation in Mind **
        Good points Brian and I also had that kind of issue on international applications I developed years ago. Specifically on externalizing to message files, some of my clients maintain the code with the text embedded in the DDS, which as you point out makes maintenance a lot easier. Prior to release, they run the DDS through a utility that generates the message files and inserts MSGID's back into the DDS. The externalized version is translated and released. Meanwhile the programmers maintain the original (embedded) version. I have to say that my sympathies are with the client. Whilst it is some years since I have been involved in application design and maintenance, if there was something wrong with the design or architecture, my mentality was that the only real solution was to fix the design, whatever those implications were, and the implications were sometimes nasty! That was also probably easier to accomplish in my environment of a commercial software developer rather than a user organization.

        Comment

        Working...
        X