Comments for J. O'Conner http://joconner.com Creating global software Fri, 13 Jan 2012 12:56:26 +0000 hourly 1 http://wordpress.org/?v=3.1.3 Comment on NetBeans 7 has no UML tools? by Houd http://joconner.com/2011/08/nb7-no-uml/comment-page-1/#comment-674 Houd Fri, 13 Jan 2012 12:56:26 +0000 http://joconner.com/?p=327#comment-674 God i'm so frustrated !!! God i’m so frustrated !!!

]]> Comment on On Sale Already? by Donna Parrish http://joconner.com/2011/12/java7-recipes-on-sale/comment-page-1/#comment-656 Donna Parrish Wed, 14 Dec 2011 13:54:18 +0000 http://joconner.com/?p=411#comment-656 Congratulations! Congratulations!

]]> Comment on Java 7 Locale Changes by Trejkaz http://joconner.com/2011/09/java7-locale-change/comment-page-1/#comment-642 Trejkaz Thu, 24 Nov 2011 20:31:47 +0000 http://joconner.com/?p=338#comment-642 Personally I think that two is nowhere near enough. here's the list of locale categories I have on my system: LANG - presumably used as the default. LC_MESSAGES - presumably what DISPLAY is set from, but being done incorrectly due to that bug in ResourceBundle which we have already discovered. LC_NUMERIC, LC_TIME, LC_MONETARY - one of these three is surely used to get FORMAT, but which one? FORMAT covers all three kinds of format according to the Javadoc so what if my system is configured to use Australian numbers and dates but Japanese currency? This was a huge oversight by the Java class library devs. LC_CTYPE, LC_COLLATE, LC_PAPER, LC_NAME, LC_ADDRESS, LC_TELEPHONE, LC_MEASUREMENT, LC_IDENTIFICATION - none of these are supported in any way at all. At least having the Category API gives them a place to start adding the rest of these. Personally I think that two is nowhere near enough. here’s the list of locale categories I have on my system:

LANG – presumably used as the default.

LC_MESSAGES – presumably what DISPLAY is set from, but being done incorrectly due to that bug in ResourceBundle which we have already discovered.

LC_NUMERIC, LC_TIME, LC_MONETARY – one of these three is surely used to get FORMAT, but which one? FORMAT covers all three kinds of format according to the Javadoc so what if my system is configured to use Australian numbers and dates but Japanese currency? This was a huge oversight by the Java class library devs.

LC_CTYPE, LC_COLLATE, LC_PAPER, LC_NAME, LC_ADDRESS, LC_TELEPHONE, LC_MEASUREMENT, LC_IDENTIFICATION – none of these are supported in any way at all.

At least having the Category API gives them a place to start adding the rest of these.

]]> Comment on Writing UTF-8 CSV Files for Excel by Jan http://joconner.com/2010/03/csv-utf/comment-page-1/#comment-628 Jan Mon, 31 Oct 2011 00:36:43 +0000 http://joconner.com/?p=226#comment-628 This is great. I think the only missing thing is the ability to customize ribbons with it these (csv addin) commands. This is great. I think the only missing thing is the ability to customize ribbons with it these (csv addin) commands.

]]> Comment on Unicode Terminology by john http://joconner.com/2011/10/unicode-terminology/comment-page-1/#comment-622 john Sun, 23 Oct 2011 22:14:28 +0000 http://joconner.com/?p=397#comment-622 yes the next blog will concentrate on these 3 and how they are formed yes the next blog will concentrate on these 3 and how they are formed

]]> Comment on Unicode Terminology by Ken Lunde http://joconner.com/2011/10/unicode-terminology/comment-page-1/#comment-621 Ken Lunde Sun, 23 Oct 2011 13:14:44 +0000 http://joconner.com/?p=397#comment-621 Good stuff. I hope that the "Next Up" topic covers what I summarize here. It is best to think of the three fundamental Unicode encoding forms -- UTF-8, UTF-16, UTF-32 -- in terms of code units. And, the names of these encoding forms conveniently and explicitly indicate the number of bits per code unit. Then, how many code units comprise a Unicode code point may depend on the BMP versus beyond-BMP distinction (one for BMP, and two for beyond-BMP, for UTF-16) or where in the BMP it is located (one, two, or three for UTF-8). UTF-32 always uses one 32-bit code unit. When thinking in terms of raw bytes, all three encoding forms require four bytes to represent Unicode code points outside the BMP. Good stuff. I hope that the “Next Up” topic covers what I summarize here. It is best to think of the three fundamental Unicode encoding forms — UTF-8, UTF-16, UTF-32 — in terms of code units. And, the names of these encoding forms conveniently and explicitly indicate the number of bits per code unit. Then, how many code units comprise a Unicode code point may depend on the BMP versus beyond-BMP distinction (one for BMP, and two for beyond-BMP, for UTF-16) or where in the BMP it is located (one, two, or three for UTF-8). UTF-32 always uses one 32-bit code unit. When thinking in terms of raw bytes, all three encoding forms require four bytes to represent Unicode code points outside the BMP.

]]> Comment on Best practice: Use UTF-8 as your source code encoding by John O'Conner http://joconner.com/2011/09/source-code-encoding-utf8/comment-page-1/#comment-608 John O'Conner Fri, 14 Oct 2011 23:51:58 +0000 http://joconner.com/?p=351#comment-608 <a href="#comment-607" rel="nofollow">@Leslie </a> Glad to hear you resolved the problem Leslie! @Leslie
Glad to hear you resolved the problem Leslie!

]]> Comment on Best practice: Use UTF-8 as your source code encoding by Leslie http://joconner.com/2011/09/source-code-encoding-utf8/comment-page-1/#comment-607 Leslie Fri, 14 Oct 2011 22:27:27 +0000 http://joconner.com/?p=351#comment-607 <a href="#comment-581" rel="nofollow">@Leslie </a> Resolved - Was just a problem communicating with the database. @Leslie
Resolved – Was just a problem communicating with the database.

]]> Comment on PDF files are bad source documents for translation? by John O'Conner http://joconner.com/2011/10/pdf-source-documents/comment-page-1/#comment-603 John O'Conner Thu, 13 Oct 2011 17:08:36 +0000 http://joconner.com/?p=393#comment-603 Thank you for your comments. Very helpful. To me, PDF files have somehow been out-featured by products like Word. PDF files seem very good at representing the visual look-and-feel or the visual intention of the author, but seem inadequate for almost anything else. The interesting thing about products like Word is that you *can* distribute locked or password protected documents to preserve the content, and I *think* it's possible to include fonts with your document so that visual representation is preserved, AND it has very nice editing/review/comment tracking too. PDF doesn't seem to fit my workflow for anything anymore, and yet I'm in an environment where PDF document distribution is the norm. Thank you for your comments. Very helpful. To me, PDF files have somehow been out-featured by products like Word. PDF files seem very good at representing the visual look-and-feel or the visual intention of the author, but seem inadequate for almost anything else.

The interesting thing about products like Word is that you *can* distribute locked or password protected documents to preserve the content, and I *think* it’s possible to include fonts with your document so that visual representation is preserved, AND it has very nice editing/review/comment tracking too. PDF doesn’t seem to fit my workflow for anything anymore, and yet I’m in an environment where PDF document distribution is the norm.

]]> Comment on PDF files are bad source documents for translation? by Jenn Mercer http://joconner.com/2011/10/pdf-source-documents/comment-page-1/#comment-600 Jenn Mercer Thu, 13 Oct 2011 14:14:01 +0000 http://joconner.com/?p=393#comment-600 1. For the love of god, yes! Because most conversion tools do not so much convert as "crack" the .pdf format either directly or using OCR. I use some pretty sophisticated tools which eliminate many of the problems which BobD mentions, but they are not free and both the initial conversion and post-formatting can take some time. 2. In my experience, it is best for the conversion to take place outside of the translation environment. 3. I translate it with a smile - but I add a surcharge and might, depending on the condition of the source document, add time for conversion and formatting. Like I said, my nice tools are not free. There are free tools available, but most of these do not preserve confidentiality or formatting. -Jenn Mercer French to English Translation 1. For the love of god, yes! Because most conversion tools do not so much convert as “crack” the .pdf format either directly or using OCR. I use some pretty sophisticated tools which eliminate many of the problems which BobD mentions, but they are not free and both the initial conversion and post-formatting can take some time.

2. In my experience, it is best for the conversion to take place outside of the translation environment.

3. I translate it with a smile – but I add a surcharge and might, depending on the condition of the source document, add time for conversion and formatting. Like I said, my nice tools are not free. There are free tools available, but most of these do not preserve confidentiality or formatting.

-Jenn Mercer
French to English Translation

]]>