I've been through some tutorials like Cross Platform App Development with Rebol 3 Saphir.
There it's mentioned the call to:
>> system/locale/months
== [
"January" "February" "March" "April" "May" "June"
"July" "August" "September" "October" "November" "December"
]
and it returns the months in english.
Furthermore, in the gui view when I try to type an ISO-8859-15 character like ç, á, à the gui doesn't allow it.
I checked my LC settings:
$ set | grep LC_
LC_ALL=pt_PT
LC_COLLATE=C
LC_MESSAGES=C
So, am I right to assume that an end user that doesn't speak English will have to adapt to the names of months in that language and will not be able to write in correct Portuguese (in this case, but it also applies to every other non-english language)?
The system/locale/months can simply be updated to anything.
system/locale/months: [ "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" ]
GUI requesters should use the data from the system object (although I have not tested this). This can be conveniently added to your rebol.r file so it is loaded on start-up.
Note that the internal date! datatype will still expect English format months for input as the locale is used for display only.
Rebol 3 supports Unicode so it should be possible to use any characters in this block.
Related
This question already has answers here:
Excal VBA - Format("7A", "00") outputs "00" while Format("7B", "00") results to the desired output of "7A". Why are they different?
(2 answers)
Closed last year.
I am baffled by the following results in the immediate execution window of VBE
print AscW("Z")
90
print Hex(AscW("Z"))
5A
print Format(Hex(AscW("Z")),"0000")
0000
print Format(&H5A,"0000")
0090
print Format(Hex(AscW("A")),"0000")
0041
It looks like Hex function returns a string, since there is no space before the returned "5A".
Perhaps Format does not work with strings?
However, "A" behaves as expected, as shown in the last line above.
What's going on? Can anyone help me?
I am using this function to emulate a case-sensitive OrderBy in Access, and this phenomenon is putting the Z strings in front of A strings and all other strings.
I found the problem.
hex of "Z" (i.e. AscW("Z")) is "5A", which contains "A", and is regarded as 0 by Format.
The reason "A" works is because its hex (AscW("A")) is "62", which is a numeric string, and Format treats it like a number.
The proper way to do it is not to use Format, but thus:
right("0000" & Hex(AscW("Z")),4)
Thanks for reading.
I have a program that checks then number of files in a selected location and then displays them. But when I tried to incorporate this into another program it bugs. Originally it worked but now it is saying something that is true is false.
set variable1 to do shell script "cd /Volumes; ls | wc -l"
display dialog variable1
This was the original program and it told me the amount of files in my volumes folder was 3.
set variable1 to do shell script "cd /Volumes; ls | wc -l"
variable1 = 3
But then I tried to incorporate it into my new program and it told me it was false!!!???
please if you can, help me as this is incredibly frustrating. Any help is great and thanks in advance!:)
Languages like AppleScript are stupidly pedantic about data types (i.e. the mechanics of how data is represented rather than what it actually means). The do shell script command returns a value of type text (aka string, Unicode text) but then your second line compares it against a value of type integer:
"3" = 3
In a sane, humane world, this comparison would return true because what you mean is obvious. Alas, the programming world is far from sane and rarely humane, and requires a level of pedantry that reduces most human beings to inchoate frustration. In this case, before you try to compare the two values you must ensure both are the same (or equivalent) type. For instance, if you want to perform a numeric comparison:
set variable1 to (do shell script "cd /Volumes; ls | wc -l") as integer
variable1 = 3
AppleScript is doubly confusing here because sometimes it performs that conversion automatically (coercion), while other times it does not, in which case you must use its at operator to explicitly convert (cast) the value yourself.
...
Oh, and the rules by which AppleScript performs numeric comparisons are different to the rules by which it performs textual comparisons, so even in situations where it will "helpfully" coerce values for you you need to be extra alert to the type(s) of the values you are working with, otherwise you can easily be caught out by even more devious and confusing bugs.
For example:
34 > 5 --> true
This first test returns true as expected, as the number 34 is greater than the number 5.
"34" > "5" --> false (?)
Text comparison compares two text values character-by-character, thus the second test returns false because the "3" comes before, not after, "5".
Furthermore, unlike the is-equal (=) and is-not-equal (≠) operators, the >, <, ≥, and ≤ operators do coerce their operands to the same type before comparing them:
34 > "5" --> true
"34" > 5 --> false
In both cases, the operator coerces its right operand to the same type as its left operand before comparing them according to numeric (in the first case) or textual (in the second) rules. This sort of behavior may be politely described as a language design flaw or "wart".
If you're even unsure what type of value the left operand will be, but want to make absolutely sure it is compared using the correct set of rules, apply the appropriate coercion to it first:
(variable1 as number) > 5
(variable1 as text) > "5"
I am just researching building a multilingual website. I've looked into database structure but I am now looking at how the URLs would work.
My main concern is that I will have an English and Chinese version of the website. I want to use search engine friendly URLs, how would this be possible with Chinese characters?
For the English site I may use something like:
www.domain.com/en/products/[productname]/
With the product name coming from the English translation in the database.
What would I do for the Chinese website?
www.domain.com/cn/products/[productname]/
Would I just be able to put the Chinese translation from the database straight into the URL?
from URLEncoder:
When encoding a String, the following rules apply:
The alphanumeric characters "a" through "z", "A" through "Z" and "0"
through "9" remain the same. The special characters ".", "-", "*", and
"_" remain the same. The space character " " is converted into a plus
sign "+". All other characters are unsafe and are first converted into
one or more bytes using some encoding scheme. Then each byte is
represented by the 3-character string "%xy", where xy is the two-digit
hexadecimal representation of the byte. The recommended encoding
scheme to use is UTF-8. However, for compatibility reasons, if an
encoding is not specified, then the default encoding of the platform
is used.
So do the encoding as specified. I guess the search engines will decode them correctly.
I'm working on an iOS app in which I have to list and sort people names. I've some problem with special character.
I need some clarification on Martin R answer on https://stackoverflow.com/a/15154823/2148377
You could use the CoreFoundation CFStringTransform function which does almost all transformations from your list. Only "đ" and "Đ" have to be handled separately:
Why this particular letter? Where does this come from? Where can I find the documentation?
Thanks a lot.
I am not 100% sure, but I think it can be seen from the Unicode Data Base
http://www.unicode.org/Public/6.2.0/ucd/UnicodeData.txt.
For example, the entry for "à" is
00E0;LATIN SMALL LETTER A WITH GRAVE;Ll;0;L;0061 0300;;;;N;LATIN SMALL LETTER A GRAVE;;00C0;;00C0
where field #6 is the "Decomposition mapping" into "a" + U+0300 (COMBINING GRAVE ACCENT),
therefore
CFStringTransform(..., kCFStringTransformStripCombiningMarks, ...)
transforms "à" into "a".
The entries for "Đ" and "đ" are
0110;LATIN CAPITAL LETTER D WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER D BAR;;;0111;
0111;LATIN SMALL LETTER D WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER D BAR;;0110;;0110
where field #6 is empty, so these characters do not have a decomposition into a "base character" and a "combining mark".
So the question remains: Which standard determines that a "normalized form" of "đ / Đ" is "d / D"?
Can anyone advise what is the ideal approach to recognize line break in a database column's data?
Using \r\n or chr(10)? What is the difference actually?
Does C# code need to do any special handling to split the lines or it will be recognized automatically?
\r is char(13) known as the "Carriage Return" character.
\n is char(10) known as the "Line Feed" character.
\r\n is char(13) + char(10) i.e. case 1 & 2 are concatenated.
Different operating systems use different combinations when reading or writing new lines in text data, the most common are:
Windows uses the combination in case 3, referred to as "Carriage Return Line Feed".
Unix and Unix-like systems use case 2, just the "Line Feed".
In C# you can handle all 3 cases by splitting the lines like this:
string[] lines = dbText.Split(new string[] { "\r\n", "\n", "\r" },
StringSplitOptions.None);
Other characters and combinations are used by other operating systems and this subject even has it's own Wikipedia page with way more detail than you'll probably ever need!