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--- Synchronet 3.21b-Linux NewsLink 1.2
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.
On Sat, 31 Jan 2026 16:10:38 -0600, Gary Scott wrote:
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...:)
ldo@theon:~> date -d "1-Jan-1066"
Mon 01 Jan 1066 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-966"
Wed 01 Jan 0966 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-866"
Fri 01 Jan 0866 00:00:00 LMT
On 2026-02-01 17:01, David Brown wrote:
...
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.
When someone from a non-English speaking country sets up
an English compatible environment, there's a pretty good chance he's
doing so to communicate with people in the US, rather than other parts
of English-speaking world.
On 02/02/2026 01:11, James Kuyper wrote:
On 2026-02-01 17:01, David Brown wrote:
...
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.
There are about 400 million native English speakers around the world,
of which about 230 are in the USA. Of course any such numbers will
be estimates, with surveys being from different years, but it
certainly looks like you overestimate the numerical ratios.
Still, the native speaker numbers are not the relevant numbers here -
it is primarily the second language users that matter. That is, of
course, even more difficult to judge well - there is no consensus on
how well a second language must be understood to count as an English
speaker. Best guesses, as far as I can see, are about 1.1 billion.
When someone from a non-English speaking country sets up
an English compatible environment, there's a pretty good chance he's
doing so to communicate with people in the US, rather than other
parts of English-speaking world.
No, by far the most likely reason for a non-native English speaker to
speak English is to communicate with another non-native English
speaker. English is the lingua franca of the world.
But my point was more about the factors /other/ than the language.
The whole world, other than the USA, uses metric for everything
technical. The whole world, other than the USA, Canada and Mexico
uses A4 and related paper sizes. The whole world, other than the
USA, uses either little-endian or big-endian dates.
Thus for perhaps 80% of people in the world using a computer and communicating in English, UK locale settings are a better fit than US
locale settings. (For many, perhaps most, other English variants -
like Indian English locale, would be even better.)
On Mon, 2 Feb 2026 11:27:53 +0100
David Brown <david.brown@hesbynett.no> wrote:
On 02/02/2026 01:11, James Kuyper wrote:
On 2026-02-01 17:01, David Brown wrote:
...
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.
There are about 400 million native English speakers around the world,
of which about 230 are in the USA. Of course any such numbers will
be estimates, with surveys being from different years, but it
certainly looks like you overestimate the numerical ratios.
Still, the native speaker numbers are not the relevant numbers here -
it is primarily the second language users that matter. That is, of
course, even more difficult to judge well - there is no consensus on
how well a second language must be understood to count as an English
speaker. Best guesses, as far as I can see, are about 1.1 billion.
When someone from a non-English speaking country sets up
an English compatible environment, there's a pretty good chance he's
doing so to communicate with people in the US, rather than other
parts of English-speaking world.
No, by far the most likely reason for a non-native English speaker to
speak English is to communicate with another non-native English
speaker. English is the lingua franca of the world.
But my point was more about the factors /other/ than the language.
The whole world, other than the USA, uses metric for everything
technical. The whole world, other than the USA, Canada and Mexico
uses A4 and related paper sizes. The whole world, other than the
USA, uses either little-endian or big-endian dates.
Thus for perhaps 80% of people in the world using a computer and
communicating in English, UK locale settings are a better fit than US
locale settings. (For many, perhaps most, other English variants -
like Indian English locale, would be even better.)
That sounds about right except for keyboard layout.
For majority of non-native English user (not necessarily speakers, many computer users can't speak English, even more can't understand English
spoken by natives, but they read and write English not too badly) US
layout would be more practical than UK layout.
On 02/02/2026 01:11, James Kuyper wrote:...
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
There are about 400 million native English speakers around the world, of which about 230 are in the USA. Of course any such numbers will be estimates, with surveys being from different years, but it certainly
looks like you overestimate the numerical ratios.
On 2026-02-02 05:27, David Brown wrote:
On 02/02/2026 01:11, James Kuyper wrote:...
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
There are about 400 million native English speakers around the world, of
which about 230 are in the USA. Of course any such numbers will be
estimates, with surveys being from different years, but it certainly
looks like you overestimate the numerical ratios.
I looked at the Wikipedia article on English (language), which says that
US has 244,079,241 native speakers of English, and that the world has 391,286,346. When I did the calculations last night, that, came out to
75%, but for some reason it's 62% this morning. Perhaps I shouldn't post
that late at night.
It's still more US speakers than non-US speakers.
If that is the case, then that is a good reason for choosing US layout.
But AFAIK the differences between the US and the UK layouts are very small. And a large proportion of computer users use Latin keyboards,
even if their native languages use significantly different writing systems. So keyboard layout is often partially independent of other language and locale choices.
For example, I use a Norwegian layout
keyboard, but have my locale set to UK (with the region set to Norway).
Changing to the UK keyboard layout would be silly - it would mean some symbols are in a different place, and I could not type the Norwegian
letters I need when writing in Norwegian.
Changing to US layout would
be a step sillier, and there would be no advantages.
If you are used to a keyboard with a different writing system - say,
Greek - then you might find it convenient to change to a Latin based
layout for writing in English.
But I see no reason why you might have a
preference for US layout over UK - either would be fine.
On 02/02/2026 15:36, James Kuyper wrote:
I looked at the Wikipedia article on English (language), [...]
I also got my numbers from Wikipedia. I think there are a variety of numbers, depending on the dates and the source of the numbers.
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.
which I call TLW "tools-logics-window"
I publish it in dec. 2024, on my WWW site under URL:
<https://energokod.gda.pl/monografie/Arch.%20Prog.%20Nieuprzywilejowanych.pdf>
Op 01.feb.2026 om 10:06 schreef Lawrence D’Oliveiro:
On Sat, 31 Jan 2026 16:10:38 -0600, Gary Scott wrote:
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...:)
ldo@theon:~> date -d "1-Jan-1066"
Mon 01 Jan 1066 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-966"
Wed 01 Jan 0966 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-866"
Fri 01 Jan 0866 00:00:00 LMT
Now it becomes important to indicate whether the Gregorian or the Julian calendar is used.
Not all countries switched at the same date.
NOTE: Do not push any "business logic" in to your libs.
On Mon, 2 Feb 2026 11:18:03 +0100, Fred. Zwarts wrote:
Op 01.feb.2026 om 10:06 schreef Lawrence D’Oliveiro:
On Sat, 31 Jan 2026 16:10:38 -0600, Gary Scott wrote:
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...:)
ldo@theon:~> date -d "1-Jan-1066"
Mon 01 Jan 1066 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-966"
Wed 01 Jan 0966 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-866"
Fri 01 Jan 0866 00:00:00 LMT
Now it becomes important to indicate whether the Gregorian or the Julian
calendar is used.
ldo@theon:~> date -d 4-oct-1582
Mon 04 Oct 1582 00:00:00 LMT
ldo@theon:~> date -d 15-oct-1582
Fri 15 Oct 1582 00:00:00 LMT
Proleptic Gregorian.
Not all countries switched at the same date.
ldo@theon:~> ncal -s IT oct 1582
October 1582
Mo 1 18 25
Tu 2 19 26
We 3 20 27
Th 4 21 28
Fr 15 22 29
Sa 16 23 30
Su 17 24 31
ldo@theon:~> ncal -s GB oct 1582
October 1582
Mo 1 8 15 22 29
Tu 2 9 16 23 30
We 3 10 17 24 31
Th 4 11 18 25
Fr 5 12 19 26
Sa 6 13 20 27
Su 7 14 21 28
ldo@theon:~> ncal -s GB sep 1752
September 1752
Mo 18 25
Tu 1 19 26
We 2 20 27
Th 14 21 28
Fr 15 22 29
Sa 16 23 30
Su 17 24
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,096 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 398:09:21 |
| Calls: | 14,036 |
| Calls today: | 2 |
| Files: | 187,082 |
| D/L today: |
2,450 files (1,578M bytes) |
| Messages: | 2,479,082 |