× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. July 2009

RE: Question(s) on converting names and addresses to UNICODE

Alan;

Why would USA(english) names/addresses be stored in Arabic or Mandarin? (unless those are the corporate "native" language)

We only have North American customers and vendors, currently, but part of our address project will be to handle non-English centric names and addresses. One of the leading ideas is to use the alias approach:
Store the names/addresses as received, in the language received, and create an alias(es) for them. Ex. Fictitious Chinese paper company name: ååè the alias would be: Consolidated Paper.
(used ms word to translate)

The two assumptions for this design:
1. Access to an external (for pay?) translation web service or an internal service.
2. Employees entering the information for non-North American customers/vendors would have some capabilities with translating from/to English

Duane Christen




--


Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Wednesday, July 22, 2009 11:32 AM
To: Midrange Systems Technical Discussion
Subject: Re: Question(s) on converting names and addresses to UNICODE


Thanks for your reply Charles
It may be a case of me not understanding what you are trying to show me (ABSOLUTELY no surprise there) but the dilemma I see us facing is that users in the US need to do a look-up for a customers name and/or address, but the customers name and/or address is held in unicode in Arabic, or Mandarin.
Again, sometimes I amaze myself at how thick and dense I can be in understanding the situation, So - please - be gentle with me



Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 07/22/2009 11:14:18 AM:

Alan,

You're probably going to want to get the Text Extenders that are part
of 5722-DE1.
http://www-01.ibm.com/software/data/db2/support/textextender/

Allows for better text searches, including "fuzzy" matches.

HTH,
Charles

On Wed, Jul 22, 2009 at 10:48 AM, Alan Shore<AlanShore@xxxxxxxx> wrote:
Thanks for your reply Duane
Even though we ARE going to 6.1, it is NOT in our near future, but
the conversion to UNICODE is however, the process of
indexing/searching names and is also something
we
HAVE to look into as well
I've already asked the question "How are our customer service dept.
going
to be able to process/analyze/investigate names and addresses in
Arabic,
Mandarin, etc.
Have you been able to find anything?



Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 07/22/2009 09:58:56 AM:

Alan;

We are looking at a project to re-architect our address and name
files, centralize and standardize them, UNICODE etc.

One of the things on my list to research is if the 6.1 support for
text indexing/searching would work for customer and/or business
names and aliases.

I have only done some cursory research on it but at the moment it
looks like it will fit our needs.

Duane Christen


--


    Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Wednesday, July 22, 2009 8:34 AM
To: Midrange Systems Technical Discussion
Subject: RE: Question(s) on converting names and addresses to
UNICODE

Morning Neill
Thanks for your reply
Now its my turn to say
I hope I haven't misread your reply We are passing the data to a
3rd party vendor software (looking back at my initial e-mail I now
realize I missed that important word -
software) This 3rd party Âsoftware is used in printing the invoice,
shipping label etc We have asked them what would it take for them
to process UNICODE fields.
There first question was, how long/big will these fields be Hence,
my question to the e-mail group


Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 07/21/2009 06:54:52 PM:

Do you really need to pass the data to a third party to convert it?
Or
have
I misread the question.

Anyway if you want your fields to be Unicode you have a couple of
choices,
CCSID 1200, 13488 or 1208. The first two are effectively the same
and
store
the values as UTF-16 the later is UTF-8 (which is becoming more
popular)

The rest of my answer depends on your answers to the following?

How many languages do you currently support?
What CCSID's are you using?
Are you prepared to recompile / refactor programs?
Whats your dev environment RPG COBOL, Synon site?

Neill

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: 21 July 2009 21:29
To: Midrange Systems Technical Discussion
Subject: Question(s) on converting names and addresses to UNICODE

Good afternoon all
I hope I can ask the correct question, so here goes We have been
asked
to look into converting our Name and address fields
from
EBCDIC to UNICODE to capture "foreign" characters Part of that
conversion is the passing of said names and addresses to a
3rd
party vendor
This is NOT really a technical question per se, but I don't
really know where to start investigating the following question.

For ALL the names and addresses that have to be captured world
wide (in whatever characters that will be passed down), what
would be considered a good "size" for fields like first name last
name
Address
lines (including street names, city names, provinces, county
names,
country names etc. etc.)
Like I said - not really a technical question, but if someone
knows the answer, or can point me in the right direction, it
would be MUCH appreciated


Thanks in advance



Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l
.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.