Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Multiple languages in one file

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

  • Multiple languages in one file

    Have you thought of using different file members. Each member would be in a different language with perhaps a different code page. An OVRDBF command would ensure that the user accesses the correct member for their location. There would only have to be a single program, and there would be no need for special logic within the program. Dave

  • #2
    Multiple languages in one file

    Hi Dave, Thanks for your reply. Indeed we have thought about using members per langauge but decided against it in order to be able to share information more easily. The principle as described for the part-description file would also be applied on any other files containing descriptions or texts. The result would be that the customer can leave his car (we're talking a Car-DMS, Car-Dealer Management System here) for repairs anywhere and the maintenance history of the car would be available to the workshop. All descriptions of parts and operation code would be displayed in the local language while written texts can obviously not be translated but should be at least visible and readable. To top if off, the system should be able to generate an invoice in the customer's language. With all vehicle transactions in the same member it will be so much easier to obtain statistics from the system while the application becomes more simple to handle and maintain. Pending the language issue obviously... The general idea is to store all descriptions in the same database in an exchangable CCSID (eg. 65535 or maybe 500) and then make the browser convert it in the correct CCSID depending on the user's configuration in Windows. With kind regards, Paul ------------------ Paul JHM van Doorn Sweden

    Comment


    • #3
      Multiple languages in one file

      Hi Paul Have you considered UNICODE ? Atleast if you are on V5R3 it should be a possibility. Go to IBM Information Center InfoCenter and search for "unicode database" . There are some concerns about displying the data in display files, but using browser should be easier. I haven't used this myself... Regards Kjell

      Comment


      • #4
        Multiple languages in one file

        paul wrote: > All descriptions of parts and operation code would be > displayed in the local language while written texts can obviously not > be translated but should be at least visible and readable. To top if > off, the system should be able to generate an invoice in the > customer's language. A quick stab at this would be to add a key field to each of the necessary files and then load the appropriate translations for each field designated by the language. This might require a major restructuring of the database since you're now dealing with multiple records per item of information. You'd likely have to split certain fields off to their own file. For instance, you might have a file called the ItemMaster which has the part number, description, weight, retail price, stocking classification. You'd have to split the description out to a separate file which uses the part number and language code as the keys. It would contain the appropriately translated description in each record. As you might guess, this can explode on you quickly. Bill

        Comment


        • #5
          Multiple languages in one file

          Unicode would indeed be the best approach. If all you had to worry about were the Western European and Scandanavian languages then you could go with a CCSID such as 500. This is because these languages share the same character set (697). You could have various users using their preferred keyboards/CCSIDs and have database normalize all data on input and output to 500. CCSID 65535 would not be adviseable as database would be unable to provide any normalization in that case. You would be responsible for correctly encoding the data (as opposed to i5/OS). HOWEVER, you did mention Eastern European languages. These languages do NOT use the same character set of Western Europe. Estonia for instance used character set 1307 which contains characters that do not exist in the character set 697 of CCSID 500. If you want to be able to store data that spans language sets (German and Estonian for instance) then Unicode is the answer. Once you've selected Unicode (CCSID 13488 or 1200) you can then store German, Estonian, Cyrillic, Hebrew, Chinese, Thai, Farsi, etc. and access it from your RPG/COBOL/etc application. This is clearly a lot more flexible. I will point out though that just because the system can now store this data, it is still up to you to make sure the data is accessed by devices capable of displaying the data. For example, a user on a Spanish device (configured with character set 697) trying to display a Greek part desription in character set 875 is not going to see Greek. They will see substitution characters due to the device being unable to display the Greek character set. The user in this case needs to be using a Greek display or using an emulator such as System i Access for Web that supports the 5250 Unicode data stream. Using a 5250 Unicode emulator would allow the user to see Spanish, Greek, and other languages concurrently. As was pointed out earlier by Kjell, you should research the Unicode capabilities of the system. Unicode was introduced way back when for just this type of application requirement. Bruce Vining

          Comment


          • #6
            Multiple languages in one file

            Hi all, We have a i5 database that we want to use more in a international way by storing texts in different languages, each with a langauge code in the same file in one library. The file would look something like this: Part-ID, Part-Langauge-ID, Part-Description Now, the field 'Part-Description' would contain texts in different languages while the field 'Part-Langauge-ID' would tell the (RPG) application what language the user prefers. The application would run in an Internet browser and the Windows language setting would be used to determine what language code was required to view the records. The reason for the 'trick' above is to avoid a lot of libraries per country as well as the possibility to share data internationally. Can anyone inform me if the scenarion above is a feasible one and if so, what things to bear in mind for configuring it successfully? The langauges being used in the database would be english, french, german, spanish, portugeese, the scandinavian langauges and the eastern european languages. Thanks in advance, Paul ------------------ Paul JHM van Doorn Sweden paul@itstajm.se

            Comment


            • #7
              Multiple languages in one file

              Hi, Thank you all that contributed in answering my question. It seems quite clear from Kjell and Bruce's entries that Unicode is the way to go so we'll start investigating this technique on the double. I am aware that whatever solution we'll choose, it will not solve all our difficulties. If it would, we'd have solved all global language problems and that is not something we want to aim for since it could easily be fixed if we'd all settle using only one langauge from now on. (I propose the Dutch langauge, all in favour raise you hand...) Indeed, the item has to be tackled on two fronts: the database: how to store the data correctly and the application: how to present it in the best readible manner. A note from my side: It seems that Unicode has many advantages in creating this sort of internationally used applications. Why is it not applied more often? I've worked for several international companies and in different countries for the last 16 years but have yet to see an application deploying Unicode... Thanks again and kind regards, Paul Paul JHM van Doorn Sweden paul@itstajm.se

              Comment


              • #8
                I am very new to dbcs. Is it better to use G type rather than O type? We want to be able to handle maintaining English, Chinese, French description in 1 table field. Thank you in advance.

                Comment

                Working...
                X