Vietnamese names with accents

[Mr.Kim.Sanders 0]

It is a reality that I personally would have names in my tree that are from all over the world, in languages as diverse as Czech, Vietnamese, Persian, Turkish, and Chinese. The reality is that the Web and even family tree programs are increasingly a Unicode world. I feel that it is, thus, not unreasonable to expect to see them in TMG in an orthographically correct manner, according to the country of origin, just as I can in my e-mail (now that I've switched from Outlook Express to Mozilla Thunderbird 2). And, from the postings I have seen on the various boards here, I know that others face the same Web reality and have similar family tree expectations. It is also a reality is that my Character Map shows up in Unicode even in my TMG (while the given edit screen is still open), so I see no "eternal" reason prohibiting TMG and all its component parts from being able to move with the times (at some point in time) to full Unicode-compatibility. The reality is that each .COM file (Visual FoxPro) can surely have its .NET counterpart. It will just a matter of knowing what the .COM extensions are for the version in question, what the conversion requires, and writing a program that implements the changes for Unicode compliancy without changing the format of the data in question. Reality (and the future) is my perspective.

Edited June 13, 2009 by Mr.Kim.Sanders

[AndyH3rd 0]

Since you have already been told, more than once, why there is no unicode in TMG I fail to see how you feel you have a right to expect it!

 

The reality is this- when TMG is unicode comptible it will be announced, until that time continued whinging about the lack of it will not speed its inclusion.

 

If you *reallY* have to have it there is a *very* simple solution, well, two actually; either buy a program that has it or write you own- your choice.

[Mr.Kim.Sanders 0]

• I suggest that my feelings and expectations have been shaped by my life-long experience — my interest in people, my attention to details such as language and culture, and my exposure to the increasingly-Unicode Internet context. I find myself increasingly interested in the world outside of my own experience and the cultures that have limited my perspective, so that these shared challenges now in mind may yet be overcome.

• If I could know which program(s) would be able to import my TMG 6.12 project of over 32900 names fully intact, that would be awesome, as would having the know-how to write such a program. But, alas, as a mere mortal, I too have my limitations. Even rocket scientists are vapourised in space every so often because they rely on the rest of the team which has remained on the ground. I am no rocket scientist. But neither am I willing to be vapourised.

• That having been said, I still feel that the goal of Unicode-compatibility is very much a worthy project. Perhaps there are yet those without monetary ambitions, whether connected to Microsoft or the Unicode Consortium or some other relevant enterprise who would gladly share their expertise. The Internet itself suggests as much, as the remainder of this post seems to indicate.

• Looking at http://www.west-wind.com/presentations/fox.../foxunicode.asp, Rick Strahl tells us (near the end of his article »The VFP user interface basically allows you to display a single code page at a time. This means that if you want to display output from multiple different locales with differing character sets you're pretty much out of luck with the native Visual FoxPro user interface.

»However, there is a workaround: You can skip using VFP controls and use ActiveX controls instead. Figure 5 shows a very simple Visual FoxPro form of the multi-language data I've been working with in this article.

 

Figure 5 – Displaying Unicode in Visual FoxPro applications requires that you use ActiveX controls. Other than the default Locale, Visual FoxPro’s native controls cannot display Unicode. This form uses the DataDynamics SharpGrid and the Microsoft Forms Editbox to display the Unicode text.«

 

 

 

• If Strahl is right, then the rest may become just a matter of the design team tackling one part at a time, so that TMG users who are not so tech-savvy might just be able to download upgrades from the WhollyGenes sites as they can be made available.

Edited June 13, 2009 by Mr.Kim.Sanders

[Maccara 0]

However, there is a workaround: You can skip using VFP controls and use ActiveX controls instead. Figure 5 shows a very simple Visual FoxPro form of the multi-language data I've been working with in this article.

 

. . .

 

The rest is just a matter of implementation so that the TMG users who are not tech-savvy can just download an upgrade from the WhollyGenes sites. Problem solved.

 

I'm afraid to tell you, but it is not as simple as you make it out to be.

 

Even the site you refer to mentions, that for these tricks to work, the back-end needs to support unicode too (which, in this case, I believe is not true, as the SQL portion is VFP (but I don't have intimate knowledge of VFP to be certain of this limitation) - the article is using SQL Server for the examples) and furthermore even bigger problem is that you then need to work with binary representations of the strings only, which makes all kinds of string operations a pain to implement. [from the article: "Unlike SQL Server or most other SQL data bases Visual FoxPro can't represent Unicode data internally unless you use a binary format to store it."]

 

I can tell from experience, that there is absolutely no point in "hacking" this kind of support as it will ultimately only lead to bugs. (my approach would be to change platform altogether to something more future-proof as VFP is officially EOL by MS - but this requires a re-write of the software and will take some time)

 

There is no simple & fast solution to this problem. I trust Wholly Genes is well aware of this issue and is working on a solution, but it won't happen overnight by some magic trick.

[Mr.Kim.Sanders 0]

Hello to all. A Google search reveals that several Databases and Repositories are now (at least partially) Unicode-compatible. The link for that is at http://www.unicode.org/resources/database.html.

I have word from someone who has studied the issue of Database-making that is now possible to take a program such as Microsoft's Access 2007, and make it look and function precisely like TMG (only built with Unicode and MS Word from the ground up). With the right development and business deals in place regarding copyright and other proprietary rights, and with the proper import converters written, then any TMG product would be able to be imported to the proposed Unicode/Word-based upgrade of any and all existing TMG products without any errors or loss of data at all. (I have already listed the file extensions for TMG 6.12 in this forum discussion; extensions added since then would just need to be added to this file extension list to make sure that importability is complete and comprehensive.)

With the availability of such a reasonable, forward-looking upgrade formula, this could enable any and all users to enter whatever biographical data in any or all Unicode-supported languages, whether they be ones derived from the Roman alphabet (such as for Western Windows, Medieval Handwritten Legal English, Vietnamese, Czech, or Turkish), or whether they be from more "exotic" scripts (such as for Greek, Russian, Arabic, Hindi, Thai, Japanese, or even Chinese).

In completion, I would further suggest that, even for indexing and display purposes, we envision the full range of TMG products as using the most advanced Unicode, MS-Word, and database technology on the Worldwide Web, so that even superscript, subscript, multi-color, multi-font, tables, and the other features found in .docx Word formats are functionable on all screens and in all settings.

It is a simple set of concepts, even though it is certainly easier said than done. It is, to say the least, the way forward.

/Mr.Kim.Sanders.

[AndyH3rd 0]

Hello to all. A Google search reveals that several Databases and Repositories are now (at least partially) Unicode-compatible. The link for that is at http://www.unicode.org/resources/database.html.

I have word from someone who has studied the issue of Database-making that is now possible to take a program such as Microsoft's Access 2007, and make it look and function precisely like TMG (only built with Unicode and MS Word from the ground up). With the right development and business deals in place regarding copyright and other proprietary rights, and with the proper import converters written, then any TMG product would be able to be imported to the proposed Unicode/Word-based upgrade of any and all existing TMG products without any errors or loss of data at all. (I have already listed the file extensions for TMG 6.12 in this forum discussion; extensions added since then would just need to be added to this file extension list to make sure that importability is complete and comprehensive.)

With the availability of such a reasonable, forward-looking upgrade formula, this could enable any and all users to enter whatever biographical data in any or all Unicode-supported languages, whether they be ones derived from the Roman alphabet (such as for Western Windows, Medieval Handwritten Legal English, Vietnamese, Czech, or Turkish), or whether they be from more "exotic" scripts (such as for Greek, Russian, Arabic, Hindi, Thai, Japanese, or even Chinese).

In completion, I would further suggest that, even for indexing and display purposes, we envision the full range of TMG products as using the most advanced Unicode, MS-Word, and database technology on the Worldwide Web, so that even superscript, subscript, multi-color, multi-font, tables, and the other features found in .docx Word formats are functionable on all screens and in all settings.

It is a simple set of concepts, even though it is certainly easier said than done. It is, to say the least, the way forward.

/Mr.Kim.Sanders.

 

Do you *honestly* believe the TMG development team is unaware of all this?

 

When they are ready to announce their development plans they will do so- until such time they won't comment.

 

[Last sentence removed by moderator. Please conduct discussions in a civil manner. jeb]

Edited April 23, 2009 by Jim Byram

[John Cardinal 0]

The above editing of Andy's post is a reminder that it never pays to respond to the trolls. If you do, the response is subject to discipline but the troll goes on his merry way, singing his one-note song.

[Mr.Kim.Sanders 0]

When I now want to keep track of "Vietnamese names with accents" in TMG itself, Western-Windows representations (though perhaps not strictly "authentic") may (at times) be effective and helpful. These are mnemonics, meaning that they have been designed to remind the user visually as to which non-Western-Windows letter or tone mark is actually used in the source document. In this category are Input Methods such as the 3 common ones which are seen at http://vietunicode.sourceforge.net/inputmethod.html — Telex Input Method (using non-Vietnamese letters), VNI Input Method (using numbers), and VIQR Input Method (using non-alphanumeric symbols). When a Vietnamese keyboard driver can be enabled, this allows the user to see authentic Vietnamese on Unicode-compliant applications. There is a caution in using the VIQR Input Method in index applications because non-alphabetic symbols are sometimes presently misinterpreted in GEDCOM conversions/ imports/ exports from the VIQR intent. A GEDCOM-surrogate may thus need to be developed, one which can handle all of these Vietnamese Input Methods.

/Mr.Kim.Sanders.

Edited May 16, 2009 by Mr.Kim.Sanders

[Mr.Kim.Sanders 0]

If a Unicode-compliant application is essential (as I find it is), it may be useful to have at least one separate document in an .rtf, .doc, or .docx format, which can be used in conjunction with one's TMG database. An .rtf has the advantage of also being readable on virtually any modern computer without dependence on any version of MS Word, unlike .doc and .docx extensions). In one particular .rtf, I have set about documenting a prototype set of translations of the elements of my own working name (Mr.Kim.Sanders) into a number of Oriental languages, including Vietnamese. "Tây-môn" (the Modern Vietnamese representation of "Mr.Kim") is straightforward enough (even in TMG, since it is composed entirely of Western-Windows elements), but the .rtf document is also able to show (what I presently understand to be) its earlier equivalent (西門: U+897F U+9580), showing the Sinogram-type Vietnamese characters for "West Gate". In TMG, I could perhaps make a Vietnamese Name-Var Tag with a GivenName of "Tây-môn (U+8975,9580)" to at least indicate the Unicode Input Method for 西門. Perhaps one day, TMG may be able to convert this Unicode Input Method shorthand "U+8975,9580" to the actual Unicode characters being discussed. (I have underlined the relevant Sinogram-type characters since this is a standard regarding such used as proper names.

/Mr.Kim.Sanders.

Edited May 16, 2009 by Mr.Kim.Sanders

[Mr.Kim.Sanders 0]

One of my .rtf documents (used as in conjunction to my TMG database) shows that my surname "SANDERS" is represented in modern Vietnamese as "VỆ". This "VỆ" could be represented in TMG as "VEEJ" (using the Telex Input Method), "VE65" (using the VNI Input Method), or "VE^." (using the VIQR Input Method). The earlier Sinogram-type equivalent (衛: U+885B) is one variation of the character which Unicode defines as "guard, protect, defend". In TMG, my Vietnamese Name-Var Tag could then have a Surname element such as "VE65 (U+885B)", to indicate both the Modern Vietnamese equivalent and the Unicode Input Method representation of its Sinogram-type predecessor. (It happens that there are 2 other Unicode Sinograms which I found to be equivalent to 衛 [u+885B], namely 衞 [u+885E] and 卫 [u+536B], which are used in Korean, Cantonese, and Mandarin citations.) I thus find my .rtf very handy to keep track of these multi-language nuances.

 

/Mr.Kim.Sanders.

Edited May 16, 2009 by Mr.Kim.Sanders