Selecting international resources using ResFind
John Williams (News)
I have tried to build into my program the possibility of using ResFind to
allow other language versions.
UK and France are fine - just a directory with that name within Resources -
but what about Netherlands? That has rather too many letters to work if
long filenames aren't available!
What should be used a sub-directory name? Is the country name just
automatically truncated?
John
--
John Williams, Wirral, Merseyside, UK - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject
for reliable contact! Who is John Williams? http://www.picindex.info/author/
Send your spam to: sa...@electronicsCHINA.com
Philip Ludlam
>
>I have tried to build into my program the possibility of using ResFind to
>allow other language versions.
>
>UK and France are fine - just a directory with that name within Resources -
>but what about Netherlands? That has rather too many letters to work if
>long filenames aren't available!
>
>What should be used a sub-directory name? Is the country name just
>automatically truncated?
I don't think I can easily test it, but when trying to access/read/write
filenames longer than the current permitted length, doesn't RISC OS
truncate the name so that if you try to access ...Netherlands... it
subverts that into ...Netherland... and the access succeeds?
[or is that only when copying files?]
Or is my guess wrong here?
Yours,
Phil L.
--
http://philipnet.com | http://director.sf.net | http://sms2003.com/philipnet/
druck
> On 6 Apr, John Williams (News) wrote:
>> UK and France are fine - just a directory with that name within Resources
>> - but what about Netherlands? That has rather too many letters to work if
>> long filenames aren't available!
>
> filenames longer than the current permitted length, doesn't RISC OS
> truncate the name so that if you try to access ...Netherlands... it
> subverts that into ...Netherland... and the access succeeds?
> [or is that only when copying files?]
>
> Or is my guess wrong here?
IIRC when accessing files on a filing system that truncates filenames, trying
to access a file or directory that has been truncated via its full name will
succeed.
e.g. If you create 'Netherlands' and it gets trunctated to 'Netherland'
You can still access use !MyApp.Res.Netherlands.Messages
HOWEVER and heres the nasty bit, if you then copy that application from the
short filename filing system to a long filename one, its no longer performs
the trunctions, and wont then allow a match.
e.g. !MyApp.Res.Netherlands.Messages will not match
!MyApp.Res.Netherland.Messages
While you could take advantage of this and supply an application in a Zip
archine with its long names, so it can be copied to either a short or long
name filing system and run form there with no problems. If someone moves the
one installed on a short name system to a long name one, it will no longer
work. Therefor I dont recommend relying on this.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
Matthew Barnett
> I have tried to build into my program the possibility of using ResFind to
> allow other language versions.
>
> UK and France are fine - just a directory with that name within Resources -
> but what about Netherlands? That has rather too many letters to work if
> long filenames aren't available!
>
> What should be used a sub-directory name? Is the country name just
> automatically truncated?
>
"fr" for France, "nl" for Netherlands, etc?
You could, if necessary, also extend with the language code, eg, "be-fr"
for Belgium (French) and "be-nl" for Belgium (Flemish).
John Williams (News)
Barnett <ne...@mrabarnett.plus.com> wrote:
> > I have tried to build into my program the possibility of using ResFind
> > to allow other language versions.
[Snip]
> How about using the country's internet domain suffix, i.e. "uk" for UK,
> "fr" for France, "nl" for Netherlands, etc?
> You could, if necessary, also extend with the language code, eg, "be-fr"
> for Belgium (French) and "be-nl" for Belgium (Flemish).
My enquiry was about using ResFind. Perhaps, on reflection, it should have
been in apps, but ResFind is a widely used utility within applications.
Of course, your suggestion would be helpful if I were designing a new
system myself from scratch, but the country settings are already defined.
Martin Wuerthner
"John Williams (News)" <UCE...@tiscali.co.uk> wrote:
> I have tried to build into my program the possibility of using ResFind
> to allow other language versions.
>
> UK and France are fine - just a directory with that name within
> Resources - but what about Netherlands? That has rather too many letters
> to work if long filenames aren't available!
>
> What should be used a sub-directory name? Is the country name just
> automatically truncated?
Simply have a look at an existing program that uses ResFind. SparkFS, for
instance, has Dutch messages. It uses the directory name "Netherland" and
it runs fine on both old-style hard discs and those supporting long names.
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
spam...@mw-software.com [replace "spamtrap" by "info" to reply]
---------------------------------------------------------------------
John Williams (News)
Martin Wuerthner <spam...@mw-software.com> wrote:
> Simply have a look at an existing program that uses ResFind. SparkFS, for
> instance, has Dutch messages. It uses the directory name "Netherland" and
> it runs fine on both old-style hard discs and those supporting long names.
Thanks, Martin - I did look around a bit, but missed SparkFS. Presumably
ResFind truncates the country name itself.
John Williams (News)
> > Simply have a look at an existing program that uses ResFind. SparkFS,
> > for instance, has Dutch messages. It uses the directory name
> > "Netherland" and it runs fine on both old-style hard discs and those
> > supporting long names.
> Thanks, Martin - I did look around a bit, but missed SparkFS. Presumably
> ResFind truncates the country name itself.
In fact it appears, now that I actually have a foreign language version
(actually French - thanks Jean-Michel) to test with, that the dutch folder
/must/ be called 'Netherlands' to work on the Iyonix.
Thus it would appear to be just the filer that does the actual truncating.
Hence a long-filename system is required to create compatible resources for
use with ResFind.
The other side is that SparkFS as it stands (at least the version I tested
with, with the dutch directory already truncated to 'Nederland' as is
Martin's) cannot be used in Dutch on a long-filename system such as the
Iyonix.
So it seems druck was right and SparkFS needs altering/updating.
I can't help but think it might be better if ResFind were altered to do the
truncating to 10 characters itself to avoid the problem, which only occurs
with the uncomfortably long 'Netherlands'. Or, alternatively, that both
options are set in the system variables, the standard and truncated
versions, where the country name is longer than 10 characters.
This latter option would avoid breaking existing apps if updating ResFind.
John Williams (News)
> > Simply have a look at an existing program that uses ResFind. SparkFS,
> > for instance, has Dutch messages. It uses the directory name
> > "Netherland" and it runs fine on both old-style hard discs and those
> > supporting long names.
> Thanks, Martin - I did look around a bit, but missed SparkFS. Presumably
> ResFind truncates the country name itself.
In fact it appears, now that I actually have a foreign language version
(actually French - thanks Jean-Michel) to test with, that the dutch folder
/must/ be called 'Netherlands' to work on the Iyonix.
Thus it would appear to be just the filer that does the actual truncating.
Hence a long-filename system is required to create compatible resources for
use with ResFind.
The other side is that SparkFS as it stands (at least the version I tested
with, with the dutch directory already truncated to 'Nederland' as is
Martins) cannot be used in Dutch on a long-filename system such as the
Iyonix.
So it seems druck was right and SparkFS needs altering/updating.
I can't help but think it might be better if ResFind were altered to do the
truncating to 10 characters itself to avoid the problem, which only occurs
with the uncomfortably long 'Netherlands'. Or, alternatively, that both
options are set in the system variables, the standard and truncated
versions, where the country name is longer than 10 characters.
This latter option would avoid breaking existing apps if updating ResFind.
John
John Williams (News)
<UCE...@tiscali.co.uk> wrote:
> Hence a long-filename system is required to create compatible resources
> for use with ResFind.
Mulling this over in the bath (too much information!), it occurs to me that
developers using pre-RISC OS 4 machines might simply include a line in
their Run file to attempt to rename any file 'Netherland' in their
resources directory to 'Netherlands'.
This would make the app portable between long and short filename systems
without losing access to any dutch resources:
IfThere <App$Dir>.Resources.Netherland Then Rename
<App$Dir>.Resources.Netherland <App$Dir>.Resources.Netherlands ~C ~V
It'll waste a bit of time on the pre-RISC OS 4 machines, but only a teeny
bit. It'll also only work on writable media.
This might be easier, though, than remembering to rename folders within
archives by clumsy copying and deleting.
I'm always forgetting to do things!
John Williams (News)
> I can't help but think it might be better if ResFind were altered
I informed Herbert zur Nedden of the perceived problem, and he is going to
modify ResFind to cope by, where the country name exceeds 10 characters in
length, looking for both the full and the truncated form on an IfThere
basis and setting the paths according to which is present.
This should solve the problem for future apps using ResFind, or for
existing apps with an updated ResFind.
In other words, with a new version of ResFind, perhaps next week, the
problem just disappears.
So keep an eye on csaa!
druck
> On 11 Apr, UCE...@tiscali.co.uk wrote:
>> The other side is that SparkFS as it stands (at least the version I tested
>> with, with the dutch directory already truncated to 'Nederland' as is
>> Martin's) cannot be used in Dutch on a long-filename system such as the
>> Iyonix.
>>
>> So it seems druck was right and SparkFS needs altering/updating.
No, theres nothing wrong with SparkFS, or FileSwitch, they all work as
intended, with the following behaviours.
* A long filename will be trancated when copied to a filing system that only
supports short names (if truncation is switched on)
* A long filename path will match a trancated filename on a short name
filing system (if truncation is switched on)
* A truncated name does not expand when copied from a short name filing
system to long name system
* A long filename path will NOT match a trancated filename on a long name
filing system
> > I can't help but think it might be better if ResFind were altered
>
> I informed Herbert zur Nedden of the perceived problem, and he is going to
> modify ResFind to cope by, where the country name exceeds 10 characters in
> length, looking for both the full and the truncated form on an IfThere
That will work for the vast majority of cases when dealing with old and new
filecore formats. But it should be noted that an arbitary filing system can
truncate at any length, for example a 8.3 DOSFS or CDFS with an ISO Level 1
CD will tuncate at 8 characters, CDFS with an ISO Level 2 will truncate at 31
characters.
Martin Wuerthner
druck <ne...@druck.freeuk.com> wrote:
> On 11 Apr 2005 "John Williams (News)" <UCE...@tiscali.co.uk> wrote:
>
> > On 11 Apr, UCE...@tiscali.co.uk wrote:
>
> > > The other side is that SparkFS as it stands (at least the version I
> > > tested with, with the dutch directory already truncated to
> > > 'Nederland' as is Martin's) cannot be used in Dutch on a
> > > long-filename system such as the Iyonix.
> >>
> >> So it seems druck was right and SparkFS needs altering/updating.
>
> No, theres nothing wrong with SparkFS, or FileSwitch, they all work as
> intended, with the following behaviours.
Well, yes, there *is* something wrong with SparkFS in that it does not use
its Dutch resources on a Dutch machine with long file names - this was the
thing the above poster asked to be fixed. As discussed before, this fix is
best done in ResFind, which SparkFS uses.
druck
> In message <e091225a...@druck.freeuk.net>
> druck <ne...@druck.freeuk.com> wrote:
>
>> On 11 Apr 2005 "John Williams (News)" <UCE...@tiscali.co.uk> wrote:
>>
>>> On 11 Apr, UCE...@tiscali.co.uk wrote:
>>
>>>> The other side is that SparkFS as it stands (at least the version I
>>>> tested with, with the dutch directory already truncated to 'Nederland'
>>>> as is Martin's) cannot be used in Dutch on a long-filename system such
>>>> as the Iyonix.
>>>>
>>>> So it seems druck was right and SparkFS needs altering/updating.
>>
>> No, theres nothing wrong with SparkFS, or FileSwitch, they all work as
>> intended, with the following behaviours.
>
> Well, yes, there *is* something wrong with SparkFS in that it does not use
> its Dutch resources on a Dutch machine with long file names - this was the
> thing the above poster asked to be fixed. As discussed before, this fix is
> best done in ResFind, which SparkFS uses.
Sorry, got completely the wrong end of the stick. All the filing system
operations are working as expected, but obviously this doesn't allow the
correct resources to be found if the directory has a short name.
John Williams (News)
druck <ne...@druck.freeuk.com> wrote:
> Sorry, got completely the wrong end of the stick. All the filing system
> operations are working as expected, but obviously this doesn't allow the
> correct resources to be found if the directory has a short name.
Good! I feel less stupid now!
Thanks, Martin.
Thanks David.
Jan-Jaap van der Geer
> In message <e091225a...@druck.freeuk.net>
> druck <ne...@druck.freeuk.com> wrote:
> > No, theres nothing wrong with SparkFS, or FileSwitch, they all
> > work as intended, with the following behaviours.
> Well, yes, there *is* something wrong with SparkFS in that it
> does not use its Dutch resources on a Dutch machine with long
> file names - this was the thing the above poster asked to be
> fixed. As discussed before, this fix is best done in ResFind,
> which SparkFS uses.
Well, if ResFind within SparkFS is going to be updated, you
'need' a new/updated version of SparkFS... So why not just release
a version with the correct directory-name? :-)
Cheers,
Jan-Jaap
John Williams (News)
Jan-Jaap van der Geer <jjvd...@zapo.net> wrote:
> Well, if ResFind within SparkFS is going to be updated, you
> 'need' a new/updated version of SparkFS... So why not just release
> a version with the correct directory-name? :-)
I have, obviously, contacted the ResFind author(s) /and/ David Pilling to
draw attention to the problem.
I haven't yet received a reply from DP, but, if HzN comes up with the
goods, then the problem will be solved as far as all apps using ResFind are
concerned, providing the authors read the appropriate group; which I assume
will be csaa!
The idea is that a new revised version of ResFind will be able to deal
transparently with the transfer of apps between 10 character and longer
(11) file/directory name systems without baulking (screwing-up)!
In reality, it is only Netherlands which creates a problem, but that is an
accident of fate!
All other 'countries' fall within the 10 character limit,
If only they had chosen 'Nederlands'!
La vie, c'est comme ça! Si ...
Erik Groenhuis
As "John Williams (News)" <UCE...@tiscali.co.uk> wrote:
> In reality, it is only Netherlands which creates a problem...
Yes, it is a fait that weighs heavily on our shoulders.
> All other 'countries' fall within the 10 character limit,
>
> If only they had chosen 'Nederlands'!
Or better yet, 'Nederland' (which is the country; 'Nederlands' is the
language).
Maybe we should just be glad they didn't go for
"Het_koninkrijk_der_Nederlanden" ("The_Kingdom_of_the_Netherlands"),
which is the official designation (compare "United Kingdom").
Actually, 'Switserland' is also a bad boy in the *countries list...
--
Erik Groenhuis http://www.xs4all.nl/~erikgrnh
== 'From:' address is a spam trap. Do not use
== See web site for email address
J.G.Harston
> In reality, it is only Netherlands which creates a problem, but that is an
> accident of fate!
>
> All other 'countries' fall within the 10 character limit,
>
> If only they had chosen 'Nederlands'!
What about 'Hong Kong'? It's got a ***y space in it! Grrr.
--
JGH
John Williams (News)
J.G.Harston <j...@arcade.demon.co.uk> wrote:
> What about 'Hong Kong'? It's got a ***y space in it! Grrr.
But it doesn't, at least on my machines, appear in the countries list.
Some that might have spaces appear to be concatenated - LatinAm,
MiddleEast, SAfrica.
I am at a loss what to make of DvorakUK and DvorakUSA.
John Cartmell
Different layout of keyboard.
--
John Cartmell john@ followed by finnybank.com 0845 006 8822
Qercus magazine FAX +44 (0)8700-519-527 www.finnybank.com
Qercus - the best guide to RISC OS computing
J.G.Harston
>
> But it doesn't, at least on my machines, appear in the countries list.
PRM3-760 lists Country 23 - Hong Kong. I've always assumed
any spaces are removed and stored messages in a 'HongKong'
directory.
> Some that might have spaces appear to be concatenated - LatinAm,
--
JGH
John Williams (News)
OK - then I /do/ need to e-mail Herbert to suggest that his update includes
converting any spaces in countries to hard spaces as well. And also to
check that spaces haven't been removed like the trailing 's'in
'Netherlands'. I suppose all possibilities need to be covered!
I will copy this to him!
After all - what else does he have to spend his weekends on? ;-)
Erik Groenhuis
> In article <4d5b0421...@tiscali.co.uk>,
> John Williams (News) <UCE...@tiscali.co.uk> wrote:
> > I am at a loss what to make of DvorakUK and DvorakUSA.
>
> Different layout of keyboard.
Shouldn't the keyboard layout be handled by, erm, *keyboard? (:-)
John-Mark Bell
Erik Groenhuis <erik...@csap.invalid> wrote:
> As John Cartmell <jo...@cartmell.demon.co.uk> wrote:
>
> > In article <4d5b0421...@tiscali.co.uk>,
> > John Williams (News) <UCE...@tiscali.co.uk> wrote:
> > > I am at a loss what to make of DvorakUK and DvorakUSA.
> >
> > Different layout of keyboard.
>
> Shouldn't the keyboard layout be handled by, erm, *keyboard? (:-)
It is. It's also set by *Country, however.
For clarity, here's how *Country, *Keyboard and *Alphabet relate to each
other:
*Alphabet - sets the system alphabet (see the output of *Alphabets for the
available alphabets. *Alphabet can take a country name as an
argument instead of an alphabet name. In this case, the
default alphabet for the specified country is selected)
*Keyboard - sets the current keyboard driver (see the output of *Countries
for the possible options)
*Country - sets _both_ of the above (again, *Countries lists the possible
options)
For example, on RISC OS 5, *Country Japan will select the Japanese keyboard
driver and set the system alphabet to UTF8. *Country UK will select the UK
keyboard driver and set the alphabet to Latin1. The country can be configured
(and thus preserved over reboot). Configuring the country to "Default" is
probably not a wise idea, however. See chapter 70 of the PRMs for more
details.
The other thing to bear in mind is that the presence of a country in the
output of *Countries does not guarantee that a suitable keyboard driver is
actually installed on the system. To do this, you need to jump through a
number of hoops (the Keyboard configuration utility (on >=RO4, at least)
already does this).
Something like this should do the necessary job (untested, in true csap
tradition):
DIM buf% 32
SYS"OS_Byte",71,255 TO,current% : REM save current keyboard number
SYS"OS_Byte",71,1+128 : REM set to UK keyboard
SYS"OS_InstallKeyHandler",0 TO kh_code% : REM read address of UK handler
REM copy UK key handler code into temporary buffer
FOR i%=0 TO 32
buf%?i% = ?(kh_code%+i%)
NEXT i%
FOR k%=0 TO 128
REM set to UK keyboard (in case it was changed under us)
SYS"OS_Byte",71,1+28
SYS"OS_Byte",71,k%+128 : REM set to keyboard k%
SYS"OS_Byte",71,255 TO,kn_temp% : REM read back set value
SYS"OS_InstallKeyHandler",0 TO kh_temp% : REM read address of new handler
IF kn_temp% <> 1 THEN
IF kh_temp% <> kh_code% OR (kh_temp% = kh_code% AND FNcc(kh_temp%)) THEN
REM real driver, do something useful with this information.
ENDIF
ENDIF
NEXT k%
SYS"OS_Byte",71,current%+128 : REM restore driver
END
DEFFNcc(b%)
LOCAL match%=FALSE
REM compare keyboard handler code with UK handler
FOR i%=0 TO 32
IF b%?i% <> buf%?i% THEN
match%=TRUE : REM they differ => we have a real driver
ENDIF
NEXT i%
=match%
John.
J.G.Harston
> OK - then I /do/ need to e-mail Herbert to suggest that his update includes
> converting any spaces in countries to hard spaces as well. And also to
Why not removing spaces in country names? I have several apps with a
'Resources.HongKong' directory, not 'Resources.Hong Kong'. Removing
spaces is also more portable.
--
JGH
John Williams (News)
> Why not removing spaces in country names? I have several apps with a
> 'Resources.HongKong' directory, not 'Resources.Hong Kong'.
My intention was that both possibilities would be covered, that is, in the
case of Hong Kong, both Hong Kong with a hard space /and/ HongKong without
any space would be looked for in turn, in the same way that Netherlands and
Switzerland would be looked for first, and then Netherland and Switzerlan.
Finding none of these would use the default (UK).
This should cover all eventualities.
I'm sorry that my intention was not clear to you. Anyway, the author has a
sounder grasp of his program and its purpose than I do.
> Removing spaces is also more portable.
I don't follow that - hard spaces in filenames were acceptable under RISC
OS 2 IIRC.
Theo Markettos
> J.G.Harston <j...@arcade.demon.co.uk> wrote:
>> Removing spaces is also more portable.
>
> I don't follow that - hard spaces in filenames were acceptable under RISC
> OS 2 IIRC.
But they're making assumptions about encoding, which is a rather foolish
thing to do when you're trying to work out which encoding to use! Top bit
set characters aren't guaranteed to have any meaning until the encoding is
defined - for example you could be using CP437 (MS-DOS codepage 437 for the
US) which has aacute in position &A0. &A0 is the hard space code in ISO8859,
where ISO8859-1 is Latin1.
IMO no software should use non-ASCII characters (those above 127) for
internal files unless it really, really needs to. Because there's no
guarantee that transferring those files to a system with another encoding
won't change the byte values in the filename.
(JOOI how does RISC OS 5 in UTF8 mode handle hard spaces in filenames? If
it does strict UTF8 it should interpret them as part of the next character)
Theo
--
Theo Markettos th...@markettos.org.uk
Clare Hall, Cambridge at...@cam.ac.uk
CB3 9AL, UK http://www.markettos.org.uk/
John-Mark Bell
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
[snip]
> (JOOI how does RISC OS 5 in UTF8 mode handle hard spaces in filenames?
The filer treats it as a character on its own (at least, that's what the
caret positioning suggests when using the cursor keys to move left/right
through the filename). It also allows you to delete it.
> If it does strict UTF8 it should interpret them as part of the next
> character)
Really? &A0 isn't a valid start byte, so I'd have thought it should be
treated as invalid (and then handled appropriately, whatever "appropriately"
happens to be ;). Entering a hard space in UTF8 mode generates &C2 &A0, which
is precisely what I'd have expected to see. Alt-160 also produces &C2 &A0,
fwiw.
John.
druck
> In article <73210e4c.05041...@posting.google.com>,
> J.G.Harston <j...@arcade.demon.co.uk> wrote:
>
> > Why not removing spaces in country names? I have several apps with a
> > 'Resources.HongKong' directory, not 'Resources.Hong Kong'.
>
> My intention was that both possibilities would be covered, that is, in the
> case of Hong Kong, both Hong Kong with a hard space /and/ HongKong without
> any space would be looked for in turn, in the same way that Netherlands and
> Switzerland would be looked for first, and then Netherland and Switzerlan.
>
> Finding none of these would use the default (UK).
I think its becoming clear why basing resource directories on the
ISO country codes rather than country names would be a better idea.
Alex Macfarlane Smith
druck <ne...@druck.freeuk.com> wrote:
> On 14 Apr 2005 "John Williams (News)" <UCE...@tiscali.co.uk> wrote:
>
> > In article <73210e4c.05041...@posting.google.com>,
> > J.G.Harston <j...@arcade.demon.co.uk> wrote:
> >
> > > Why not removing spaces in country names? I have several apps with a
> > > 'Resources.HongKong' directory, not 'Resources.Hong Kong'.
> >
> > My intention was that both possibilities would be covered, that is, in the
> > case of Hong Kong, both Hong Kong with a hard space /and/ HongKong without
> > any space would be looked for in turn, in the same way that Netherlands and
> > Switzerland would be looked for first, and then Netherland and Switzerlan.
> >
> > Finding none of these would use the default (UK).
>
> I think its becoming clear why basing resource directories on the
> ISO country codes rather than country names would be a better idea.
Or just based on the Territory number :) (ala what's returned by
Territory_Number)
Alex.
--
E-mail: al...@archifishal.co.uk
WWW: http://www.archifishal.co.uk/
MSN: archi...@gmx.co.uk
John Williams (News)
Alex Macfarlane Smith <nos...@archifishal.co.uk> wrote:
> > I think its becoming clear why basing resource directories on the
> > ISO country codes rather than country names would be a better idea.
> Or just based on the Territory number :) (ala what's returned by
> Territory_Number)
Easy enough to map the former to the latter?
druck
Well I was going to suggest that, but numbers aren't very friendly.
You'd have to go to the documentation to find 23, but you might have
chance of working out 'hk'.
John Tytgat
A much better idea because 1 country doesn't mean 1 language, or 1
keyboard layout.
John.
J.G.Harston
> > > I think its becoming clear why basing resource directories on the
> > > ISO country codes rather than country names would be a better idea.
> >
> > Or just based on the Territory number :) (ala what's returned by
> > Territory_Number)
>
> Well I was going to suggest that, but numbers aren't very friendly.
> You'd have to go to the documentation to find 23, but you might have
> chance of working out 'hk'.
Also, you can only map territory numbers to names if you have a module
installed that knows about them. I known that '23' means Hong Kong, and
I can configure an application to look for "Resources.HongKong", but
the CMOS RAM only holds a number, and without a suitable module installed,
Territory_NumberToName is not going to return "Hong Kong".
--
JGH
Theo Markettos
> In message <RXc*Rd...@news.chiark.greenend.org.uk>
> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>> character)
>
> Really? &A0 isn't a valid start byte, so I'd have thought it should be
> treated as invalid (and then handled appropriately, whatever "appropriately"
> happens to be ;). Entering a hard space in UTF8 mode generates &C2 &A0, which
> is precisely what I'd have expected to see. Alt-160 also produces &C2 &A0,
> fwiw.
Sorry, misread the UTF8 spec. Good to see that it's Doing The Right Thing -
the sooner we can all live in UTF8 land the better...
Theo
Jan-Jaap van der Geer
Well, aren't these resources more language-dependant than
territotory-dependant? It seems wrong to me to base the resources
on territories/countries because that would mean duplicating the
resources for every territory/countries that uses the same language
as another territory/country does.
Cheers,
Jan-Jaap
Erik Groenhuis
> Sorry, misread the UTF8 spec. Good to see that it's Doing The Right Thing -
> the sooner we can all live in UTF8 land the better...
Can't we go straight to UTF16 ? All this mucking about with
complicated encodings...
Tom Hughes
Erik Groenhuis <erik...@csap.invalid> wrote:
> As Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>
> > Sorry, misread the UTF8 spec. Good to see that it's Doing The Right Thing -
> > the sooner we can all live in UTF8 land the better...
>
> Can't we go straight to UTF16 ? All this mucking about with
> complicated encodings...
Well UTF16 is complicated as well - if you want a constant size
then UTF32 is the only choice.
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
John-Mark Bell
Tom Hughes <t...@compton.nu> wrote:
> In message <0c52f45...@domovertus.xs4all.nl>
> Erik Groenhuis <erik...@csap.invalid> wrote:
>
> > As Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> >
> > > Sorry, misread the UTF8 spec. Good to see that it's Doing The Right
> > > Thing - the sooner we can all live in UTF8 land the better...
> >
> > Can't we go straight to UTF16 ? All this mucking about with
> > complicated encodings...
>
> Well UTF16 is complicated as well - if you want a constant size
> then UTF32 is the only choice.
Neither of which are backwards compatible with existing applications - Try
printing UTF-16 encoded text for an excellent example of this. For most
applications, UTF-8 is also the most compact representation (although, if
using large numbers of ideographic characters, UTF-16 might be better). Also,
the existing C string functions work perfectly well with UTF-8. TBH, the
only time it's ever an issue that your text is represented in UTF-8 is if
you're performing some kind of processing upon it (and most applications
don't). Equally, converting UTF-8 into UCS4 (or vice-versa) is simply a
bunch of bit manipulation operations.
John.
John Tytgat
> Well, aren't these resources more language-dependant than
> territotory-dependant? It seems wrong to me to base the resources
> on territories/countries because that would mean duplicating the
> resources for every territory/countries that uses the same language
> as another territory/country does.
Then you would miss subtilities like e.g. the difference in decimal dot
or e.g. thousand separator between e.g. the territories "Belgie -
Vlaanderen" and "Nederland" although those two territories share the
same language, currency, etc.
I don't think the duplication of some of the Resources is something to
really worry about.
John.
John Williams (News)
Herbert's new version of ResFind version 2.11 is on the website at:
http://www.gag.de/software/ResFind/dload.html
This now deals correctly with long country names on long-filename systems
by first looking for the full country name, then, if not found and longer
than 10 characters, looks for a 10 character truncated version.
This means portability between systems is improved.