I knew it was bad, but not that bad.
On Fri, 23 Jan 2026 21:35:54 -0600, Lynn McGuire wrote:
I knew it was bad, but not that bad.
Back in earlier Web 1.0 days, I developed an online shop system for
a client, that had to be localizable for different target markets -- different currencies, different languages.
I developed a templating system, which allowed the code to substitute
strings into other strings, making choices according to numbers of
items (for singular-versus-plural cases), gender etc. Since the
placeholders were substituted by name, not position, this allowed for differences in grammar (e.g. verb-noun ordering).
As new languages came along with more grammatical peculiarities, I
added new templating cases, that could substitute to exactly the same
strings for existing languages. For example, a list of items in
English might expand to one of
1 item -- ?A?
2 items -- ?A or B?
3 or more items -- ?A, B, ... C or D?
whereas in Japanese, the case with 3 items has to be distinguished
from the ones with 4 or more items.
The hard part was explaining the templating system to translators. I
tried giving copious examples of how the substitutions would work in
specific cases. As I recall, I still had to do some massaging of the
strings they sent back, in some cases having to guess what they meant,
and then get them to test the results, to confirm with them that the
site was producing the correct messages in all cases.
"Internationalis(z)ing Code - Computerphile"
https://www.youtube.com/watch?v=0j74jcxSunY
"Catering for a global audience is difficult, Tom takes us through a 'timezones' style explanation of the things you need to keep in mind
when internationalising your code."
I knew it was bad, but not that bad.
Yup, I just write and sell my software in American English. I've got
enough problems without having to deal with localization.
One of my programmers has been working on converting our Windows user interface, written in 450,000 lines of C++, from Ascii to Unicode for
two years now. It was a one year project to start and his latest
estimate is another year to complete.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
"Internationalis(z)ing Code - Computerphile"
https://www.youtube.com/watch?v=0j74jcxSunY
"Catering for a global audience is difficult, Tom takes us through a
'timezones' style explanation of the things you need to keep in mind
when internationalising your code."
I knew it was bad, but not that bad.
Yup, I just write and sell my software in American English. I've got
enough problems without having to deal with localization.
You can probably get by with engineering software.
One of my programmers has been working on converting our Windows user
interface, written in 450,000 lines of C++, from Ascii to Unicode for
two years now. It was a one year project to start and his latest
estimate is another year to complete.
Like the early history of Fortran - when people ask when the project
was going to be finisehd, the answer was always "in six months".
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
[...]˙I've got enough problems without having to deal with localization.
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods.
Shoot, people can't
even agree on periods or commas for the fractional part.
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods. Shoot, people can't
even agree on periods or commas for the fractional part.
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods. Shoot, people can't
even agree on periods or commas for the fractional part.
This is where you should automatically query the locale settings.
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods. Shoot, people can't
even agree on periods or commas for the fractional part.
This is where you should automatically query the locale settings.
On 1/25/2026 7:42 PM, Lawrence D?Oliveiro wrote:
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I
sell 40% of my software outside the USA, just periods. Shoot,
people can't even agree on periods or commas for the fractional
part.
This is where you should automatically query the locale settings.
Yup, only if I had the time. I am at 15% of converting my Fortran
code to C++. 800,000 lines of Fortran code with 700,000 lines to go.
I got my input parser on my data reduction software to working in
C++ just last Thursday.
Lynn
On 2026-01-25 22:21, Lynn McGuire wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
[...]˙I've got enough problems without having to deal with localization.
Getting all right if implementing things from scratch is demanding.
(Luckily software and systems nowadays handle that for us.)
$ LC_NUMERIC=de_DE.UTF-8 printf "%9.3f\n" 1.234,567
1234,567
$ LC_NUMERIC=en_US.UTF-8 printf "%9.3f\n" 1,234.567
1234.567
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods.
That, OTOH, is just the trivial part. Even some old languages (like
Simula) allowed to change the decimal mark character for read/write
of real numbers. Since you just need that function on the interface
level it can be done in one place (presuming you use the respective
function, or redefine your own); the internal representation may be
all the same. So just define the numeric separators in the program's >environment.
Shoot, people can't
even agree on periods or commas for the fractional part.
Are you really complaining about characteristics of people's (or
nation's) historic conventions?
I started writing Fortran code in 1975 for one of my dad's programmers
when I was 14. Dad was always selling the future capabilities of the software, more than the software did or was even designed to do.
On Mon, 26 Jan 2026 00:45:41 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
On 1/25/2026 7:42 PM, Lawrence D?Oliveiro wrote:
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I
sell 40% of my software outside the USA, just periods. Shoot,
people can't even agree on periods or commas for the fractional
part.
This is where you should automatically query the locale settings.
Yup, only if I had the time. I am at 15% of converting my Fortran
code to C++. 800,000 lines of Fortran code with 700,000 lines to go.
I got my input parser on my data reduction software to working in
C++ just last Thursday.
Lynn
How many of your grandchildren are working on this software?
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I started writing Fortran code in 1975 for one of my dad's programmers
when I was 14. Dad was always selling the future capabilities of the
software, more than the software did or was even designed to do.
Sounds an awful lot like Bill Gates, but he even sold software
that had not even been written. There is a story where he wrote a
Fortran compiler, which failed tests and was therefore not accepted,
and he refused to fix the bugs.
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran 90 compiler and relabeled it.
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran
90 compiler and relabeled it.
Lynn
On Tue, 27 Jan 2026 01:46:43 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran
90 compiler and relabeled it.
Lynn
There is a big chance that you don't remember correctly.
At least it is different, not to say opposite, from the story that I
read in other places.
They say that when Microsoft found out that support for F90 is
necessary for continuation of their Fortran business then they
decided that their compilers stuff has more important things to
do. So they sold their compiler sources and Powerstation brand to
Digital that later became Compaq and later yet before merger with HP
sold it to Intel where it either replaced Intel's own Fortran compiler
or was merged with it. The last part of the story is not conclusive.
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
On 1/26/2026 11:46 PM, Lynn McGuire wrote:
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran 90
compiler and relabeled it.
Kind of reminded me of, god what was that C++ std lib they licensed for
msvc 6.0. Damn I cannot remember the name right now... search...
Dinkumware! Ahhh.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 1/26/2026 11:46 PM, Lynn McGuire wrote:
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran 90
compiler and relabeled it.
Kind of reminded me of, god what was that C++ std lib they licensed for
msvc 6.0. Damn I cannot remember the name right now... search...
Dinkumware! Ahhh.
To be fair dinkum about it, the company name was not derogatory.
IME, locale settings can be a bigger hinder than help, especially onRight. When using locales, the result of the program run is not
Windows and with MS Office.
Locales are only useful when displaying info directly for the user to
view.
Alas, most C++ projects are not GUI, but much lower level libraries
where there is no connection between the current machine
locale and the locale of the human viewer
who might eventually view the produced data.
Moreover, most produced text data is consumed by other
software nowadays,
not humans, and having to deal with varying locales
just breaks or at least complicates the things here.
So locale-dependent
behavior should not be the default, but rather something to be ordered explicitly and used rarely.
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or semicolon separated formats to be opened in a spreadsheet, or has some
other connection to MS Office programs, you have to use the formats that
the locale wants, not the formats the current user wants.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
David Brown <david.brown@hesbynett.no> schrieb:
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or
semicolon separated formats to be opened in a spreadsheet, or has some
other connection to MS Office programs, you have to use the formats that
the locale wants, not the formats the current user wants.
That is so true. Localization in MS Office is a pain, and the different
CSV formats are horrible.
On my personal PC, I have set the decimal separator, with German
settings otherwise, to a dot. This makes data interoperable
with all sorts of scripts and other programs that I tend to use
togetether with data from Excel files. Using tab as a separator works
pretty well then, it is at least unique.
I do have another computer, used as a workstation, which I keep
on US English settings. This allows easier communication with,
for example, international support for programs which originate
outside of Germany. It also allows me to have the original Excel
function names, which are also localized. Luckily, I can save
an Excel file in English and than open it on my German-language
computer in German.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or
decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
On 30/01/2026 21:28, Thomas Koenig wrote:
David Brown <david.brown@hesbynett.no> schrieb:
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or
semicolon separated formats to be opened in a spreadsheet, or has some
other connection to MS Office programs, you have to use the formats that >>> the locale wants, not the formats the current user wants.
That is so true. Localization in MS Office is a pain, and the different
CSV formats are horrible.
On my personal PC, I have set the decimal separator, with German
settings otherwise, to a dot. This makes data interoperable
with all sorts of scripts and other programs that I tend to use
togetether with data from Excel files. Using tab as a separator works
pretty well then, it is at least unique.
I do have another computer, used as a workstation, which I keep
on US English settings. This allows easier communication with,
for example, international support for programs which originate
outside of Germany. It also allows me to have the original Excel
function names, which are also localized. Luckily, I can save
an Excel file in English and than open it on my German-language
computer in German.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or >>> decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
On 30/01/2026 21:28, Thomas Koenig wrote:and sane dates...
David Brown <david.brown@hesbynett.no> schrieb:
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or
semicolon separated formats to be opened in a spreadsheet, or has some >>>> other connection to MS Office programs, you have to use the formats that >>>> the locale wants, not the formats the current user wants.
That is so true. Localization in MS Office is a pain, and the different >>> CSV formats are horrible.
On my personal PC, I have set the decimal separator, with German
settings otherwise, to a dot. This makes data interoperable
with all sorts of scripts and other programs that I tend to use
togetether with data from Excel files. Using tab as a separator works
pretty well then, it is at least unique.
I do have another computer, used as a workstation, which I keep
on US English settings. This allows easier communication with,
for example, international support for programs which originate
outside of Germany. It also allows me to have the original Excel
function names, which are also localized. Luckily, I can save
an Excel file in English and than open it on my German-language
computer in German.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or >>>> decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
Date format is adjustable in many applications.˙ Choose the one you
want.˙ Flexibility is taken to a bit extreme in GINO graphics libraries
(a UK product), with a calendar that goes all the way back to 1066...:)
Flexibility is taken to a bit extreme in GINO graphics libraries (a
UK product), with a calendar that goes all the way back to 1066...:)
On 30/01/2026 21:28, Thomas Koenig wrote:
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
On 1/31/2026 12:50 PM, G wrote:
In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
On 30/01/2026 21:28, Thomas Koenig wrote:
and sane dates...I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings.˙ Then at least you get sane paper
sizes and measurement units.
Date format is adjustable in many applications.˙ Choose the one you
want.˙ Flexibility is taken to a bit extreme in GINO graphics libraries
(a UK product), with a calendar that goes all the way back to 1066...:)
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects.˙ (Or perhaps "less terrible" is more
accurate?)
David Brown <david.brown@hesbynett.no> schrieb:
On 30/01/2026 21:28, Thomas Koenig wrote:
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
That is better, thanks!
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
I find Impress to be very difficult to work with, compared to
PowerPoint.
But the most recent thing that drove me up the wall
was Excel's inability to display a bar graph with non-overlapping
bars for a primary and secondary axis, so I can display data like
a 2 0.1
b 3 0.3
c 5 0.2
in a sane way. Libreoffice Calc can actually do this.
On 31/01/2026 23:10, Gary Scott wrote:
On 1/31/2026 12:50 PM, G wrote:
In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
On 30/01/2026 21:28, Thomas Koenig wrote:
and sane dates...I have not yet succeeded in getting LibreOffice to display a decimal >>>>> point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings.˙ Then at least you get sane paper
sizes and measurement units.
Indeed.˙ Some countries use little-endian dates, some use big-endian
dates, and one country likes muddled-endian dates :-)
Date format is adjustable in many applications.˙ Choose the one you
want.˙ Flexibility is taken to a bit extreme in GINO graphics
libraries (a UK product), with a calendar that goes all the way back
to 1066...:)
Dates from long ago can be very important, and challenging to get right.
˙But I doubt that there is a lot of overlap between people interested
in programming with graphics libraries and people trying to match up
exact dates a millennium ago!
(In the MS Office vs. LibreOffice comparison, Excel famously thinks 1900
was a leap year.˙ And rather than fix the problem, MS bullied it in as
an ISO standard.)
LibreOffice has its faults and weaknesses, but it is still far ahead of >>>> MS Office in many aspects.˙ (Or perhaps "less terrible" is more
accurate?)
I fully understand why many people from non-English-speaking countries sometimes find it best to have an English locale or language settings on their systems. But I have never understood why they pick US English forBecause the US is fairly big, and has economic power disproportionate to
the purpose. Despite the Brexit madness, UK standards are far closer to European norms than the US standards are. And for many purposes, those norms are nearly global - the US is the only one that is different.
On 2026-02-01 05:35, David Brown wrote:
...
I fully understand why many people from non-English-speaking countriesBecause the US is fairly big, and has economic power disproportionate to
sometimes find it best to have an English locale or language settings on
their systems. But I have never understood why they pick US English for
the purpose. Despite the Brexit madness, UK standards are far closer to
European norms than the US standards are. And for many purposes, those
norms are nearly global - the US is the only one that is different.
it's size, so it's peculiarities get catered to more often than might otherwise seem justified. I am a US citizen, but I'm not endorsing this, merely describing it.
But when people in other countries want to choose an English language environment (because English has a lot of influence on the world - for
good reasons and bad reasons), why pick an environment that has more incompatibilities and baggage than necessary? I expect it is mostly a
matter of sticking to default choices unless you know you need
something different, and simply not thinking about the alternatives.
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 24:11:08 |
| Calls: | 117 |
| Calls today: | 117 |
| Files: | 368 |
| D/L today: |
560 files (257M bytes) |
| Messages: | 70,913 |
| Posted today: | 26 |