|
Check on the vendor that wrote the package. This is not a new problem. Check on the 3rd party outfits that service that package ... BPCS must have scores of them ... you may be able to find another outfit that has solved this & you can contract with them to have this installed at your customer with you getting some of the $$$. We have had scenarios with customs forms that have to be intelligible in more than one language at the same time, such as English and Portugese, and we know that the package will be transiting Spanish speaking in between the two. Many software packages use the IBM multiple human language feature both for global users internally signing onto the system, and for output by software to external users, such as via reports. However, the state of art of language translation by computer is not as great as by human & some software may need to be tweaked to make text intelligible. I cannot believe that changing LANGID in mid stream job is magically going to get you the right words in an application, arranged grammatically correctly for that language. Every place you now use a literal in RPG, like "Discount" or "Terms" you will have to substitute a field name or pointer to that word, in which you have populated it from either the English collection or whatever language is relevant to whoever you doing business with. We just had a thread in BPCS_L about checks sent to Mexico in which they correctly printed the Spanish words for the individual numbers in the check, but when strung together they were not stated correctly according to banks in Mexico, in the same sense that "Invoice for Fences" is a correct translation of "Bill Gates" but not what the customer probably wants, or another example ... start with "Hydro Electric Dam" and get "Electronic Water Buffalo" if the state of art is just to substitute words that mean the same thing in another language, or possibly get in trouble for allegedly using swear words. I believe BPCS uses a system of Message File "BPCS Literals" in which a particular number means a particular word, so any language can be substituted which works only for individual words, not text strung out like in a paragraph. A separate named member or in separate library for each language in which the reference identities are the same ... like PAY0001 might be "Pay" in the English one & whatever the equivalent word in the other languages ... be careful to allow for the longest possible length of translation when parsing whatever comes back from look-up. You may or may not be able to do a check run or an invoice run in which 100% of the output belongs in the same language, so you have to be able to programmatically recognize language for current control break, then get all the right fields populated in that language if it is a different one than in the previous control break. Assuming you have someone on staff or on call who can translate paragraphs so that they are intelligible in the other languages & all you need are key words in the right language, and the application does not already have some built-in multi-language capability, then I would create a table in which one dimension is the languages we need to do business in & another dimension are the words that need to be translated & there is a related issue of making allowance for largest word that might be needed in the future & how you handle those funny character symbols that some languages need floating above some letters ... you may be able to do it via the HEX key on AS/400 keyboards for EBCDIC but that stuff does not always translate good to ASCII printers. Connect this to a code in each customer or vendor for which language needed, with default being English. You may need to add some stuff to the invoice that is "understood" in English speaking countries, like the desired currency to pay back in, and review what all is pre-printed on the invoice, some of which may also need translation. I once worked at a company in which we had standard English paragraphs communicating common statements in business, which we paid someone to translate for us, then staff could cut & paste the paragraphs they wanted ... so long as they did not need to change the "English Master paragraphs" to make the message make sense, then we just substituted the corresponding foreign language paragraphs & hoped that what we were sending was understandable ... we still had to pay someone to translate the correspondence that came to us from the foreign country & ask the translator to review our standard paragraphs to see if anything needed adding to the collection. > From: drasch@mail.win.org (Dan Rasch) > > I just had a customer call with an interesting problem. He prints > invoices that are mailed to various parts of the world, and wants them in > Spanish, French and English depending on the customer. I told him I was > aware of only the QLANGID, which is system-wide. > > What is the preferred method of changing languages mid-stream in a job? > Is it just to change QLANGID back and forth? This really seems a bit too > simple... leif@leif.org writes: > Different languages may use character sets that are different from the > one used on your system (extreme case: English vs Japanese), so > the message may not print or display correctly depending on the > device. Yes - in addition to figuring out how to interject those weird dots and angled lines over & above some letters, you want to be sure your printer can handle this. We often have people sending output to one printer then transferring it to another printer, so we have to do department education ... this or that printer cannot handle this or that output. I believe there is a character set issue ... Chinese & Russian are other ones ... it is not merely using letters in the English language & a few odd additions. Al Macintyre ©¿© http://www.cen-elec.com MIS Manager Programmer & Computer Janitor +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.