php-i18n Digest 12 Jan 2003 17:37:53 -0000 Issue 142
Topics (messages 400 through 408):
Re: ctype extension mb safe?
400 by: Moriyoshi Koizumi
403 by: Moriyoshi Koizumi
406 by: Jan Schneider
Re: Mb_output_handler and Shift-JIS
401 by: Moriyoshi Koizumi
402 by: David Powers
Problem with gettext
404 by: Marcos Lois Bermúdez
407 by: Jan Schneider
Installing php4.3.0 on hpux11.00
405 by: Taylor Lewick
imap_utf7_[en|de]code, from/to which charset?
408 by: Jan Schneider
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
On Thu, Jan 09, 2003 at 06:20:32PM +0100, Jan Schneider wrote:
> The subject says all. Is it?
I have to say no. It's too libc dependent, and most libc including
msvcrt doesn't handle them correctly.
I'm planning to work on this issue.
Moriyoshi
--- End Message ---
--- Begin Message ---
> I have to say no. It's too libc dependent, and most libc including
> msvcrt doesn't handle them correctly.
^^^^
I meant by this "most libc including msvcrt don't handle multibyte
characters correctly :-)
Moriyoshi
--- End Message ---
--- Begin Message ---
Moriyoshi Koizumi wrote:
On Thu, Jan 09, 2003 at 06:20:32PM +0100, Jan Schneider wrote:
The subject says all. Is it?
I have to say no. It's too libc dependent, and most libc including
msvcrt doesn't handle them correctly.
OK, I can write some of these test in PHP. But is there any way to get
the unicode class information (like if it's a letter character) for
multibyte strings/characters?
Jan.
--- End Message ---
--- Begin Message ---
Hello,
On Tue, Jan 07, 2003 at 01:18:35PM -0000, David Powers wrote:
> Perhaps I am misunderstanding how PHP works in Japanese. Let me explain
> briefly what it is I am doing. I'm sure it's the way a lot of PHP users
> in Japan are operating, but since I live in London, it's not possible
> for me to visit a user group or do some tachiyomi in a computer
> bookstore.
Japanese developers has continuously been suffering from this moji-bake
issue too and quite a few guys among them don't know even why moji-bake
occurs. So it seems I'm hardly able to explain it in a nutshell.
I guess the text I'm mentioning below may help you and so does a book
by the auther. Although the intended audience is a rather expertised
developer, this is worth a look.
ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf
> I have several websites that use PHP and MySQL to generate content in
> both English and Japanese. The remote server is Red Hat Linux 6.2 with
> PHP 4.3.0 and mbstring enabled. Most of the content is generated in
> Microsoft Word, and entered into the database using forms generated and
> processed by PHP. I also need visitors to be able to fill in online
> forms that can be mailed back to me. Since most Japanese people are
> likely to be using Windows, their input is likely to be in SJIS.
Microsoft Word is not capable of handling multiple charsets other than SJIS.
If you want to use it with PHP, you should apply encoding conversion filter
such as iconv or nkf to the generated pages before you get them parsed by php.
> What is the best configuration? If I set everything to EUC-JP, how would
> the input from the online forms be handled? If Japanese ISPs offer PHP
> services, they must have thousands of customers using Windows machines
> to create their input, or is everything like that run on ASP?
Browsers send the input by the encoding(charset) in which the page that
contains the form is written regardless of the platform they run on.
> > unfortunately i don't seem to be allowed to use japanese characters
> > in this list, I couldn't give you any example in this mail.
> > I'll come up with those again if you can read Japanese mails with
> > your mail client.
>
> Feel free to mail me directly in Japanese.
I'm going to make a quick webpage about this instead of directing it
as a mail to you. Please wait until it's completed.
> I am not a computer expert, although most people would regard me as an
> advanced user of HTML and CSS. If you can point me in the direction of g
> ood quality explanations in Japanese, I will be quite happy to study
> them. I've been reading Japanese for more than 20 years, so that is not
> a problem. It's searching through hundreds of irrelevant messages in a
> newsgroup that I don't really have time for.
Then, why don't you subscribe the Japanese PHP user list and ask your
question there? The subscribers may lead you to the right direction.
I'll be glad to see you at the list.
> Once I get things sorted out, I would be very happy to assist by
> creating a brief guide in English to setting up PHP to handle Japanese.
> A lot of the current PHP documentation is difficult for the non-expert
> to understand. I review web design books on a regular basis, and a
> leading computer publisher has told me it is very interested in
> including more on i18n and l10n in its publications, so this could serve
> a dual purpose.
Sounds interesting! I'll drop you a line if I need your assistance.
Moriyoshi
--- End Message ---
--- Begin Message ---
Moriyoshi Koizumi wrote:
>
> Japanese developers has continuously been suffering from this moji-
> bake issue too and quite a few guys among them don't know even why
> moji-bake occurs. So it seems I'm hardly able to explain it in a
> nutshell.
>
> I guess the text I'm mentioning below may help you and so does a book
> by the auther. Although the intended audience is a rather expertised
> developer, this is worth a look.
>
> ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf
Yes, mojibake problems do seem to lead a life of their own - very
unpredictable. The article you mention is by Ken Lunde. I've got his
book "CJKV Information Processing" and refer to it from time to time. It
is, as you say, very specialized, but I find it quite useful, even
though I don't understand everything. I've been reading it since last
writing to you, and see he refers to EUC as being more stable for
Japanese and other East Asian languages. So that's obviously a direction
I need to be moving towards.
> Microsoft Word is not capable of handling multiple charsets other
> than SJIS. If you want to use it with PHP, you should apply encoding
> conversion filter such as iconv or nkf to the generated pages before
> you get them parsed by php.
Right, I'll look into it.
> Browsers send the input by the encoding(charset) in which the page
> that contains the form is written regardless of the platform they run
> on.
Ah, that's very useful to know. So presumably material generated in
Shift_JIS can be uploaded through a form on EUC-JP page, and it will be
converted into EUC-JP. Or have I misunderstood?
> I'm going to make a quick webpage about this instead of directing it
> as a mail to you. Please wait until it's completed.
I'm sure that will be very useful to many people, not just myself. Thank
you.
> Then, why don't you subscribe the Japanese PHP user list and ask your
> question there? The subscribers may lead you to the right direction.
> I'll be glad to see you at the list.
I might do so, but I'm very busy. Reading Japanese is one thing. Writing
a question that will make sense is another. Still, if people like you
can write so well in English, I shouldn't be lazy about writing in
Japanese either.
>> Once I get things sorted out, I would be very happy to assist by
>> creating a brief guide in English to setting up PHP to handle
>> Japanese. A lot of the current PHP documentation is difficult for
>> the non-expert to understand. I review web design books on a regular
>> basis, and a leading computer publisher has told me it is very
>> interested in including more on i18n and l10n in its publications,
>> so this could serve a dual purpose.
>
> Sounds interesting! I'll drop you a line if I need your assistance.
Please do.
Thanks for everything,
David Powers
--- End Message ---
--- Begin Message ---
I have RH7.3 with php and gettext support, and i get this strange beaviour:
if the mo files are under document root of web server seems to work well,
but if put the mo files in a directory outside the doc root of the web
server it work some times, i get the messages translated, but when i reload
the page some times i get no translated the page in some times.
It's normal?
it's a bug?
Regards.
-----------------------------------------------
Marcos Lois Bermúdez
[EMAIL PROTECTED]
IQC - Services
Avda. Garcia Barbón, 90 / 4ºB
36201 Vigo (Pontevedra)
Tel: +34 986.884.244
Fax: +34 986.415.074
http://www.iqc-services.com
-----------------------------------------------
--- End Message ---
--- Begin Message ---
Marcos Lois Bermúdez wrote:
I have RH7.3 with php and gettext support, and i get this strange beaviour:
if the mo files are under document root of web server seems to work
well, but if put the mo files in a directory outside the doc root of
the web server it work some times, i get the messages translated, but
when i reload the page some times i get no translated the page in some
times.
It's normal?
it's a bug?
Yes. Yes.
Using gettext in PHP I have seen strange behaviour so often I can't count.
This particular behaviour can sometimes be fixed by restarting the
webserver. No idea why.
Jan.
--- End Message ---
--- Begin Message ---
Hi all. I have apache 1.3.27 and php4.3.0 installed on my HP-UX machine.
Now I want to load php into apache. So I ran the ./configure-status
--activate-module=src/modules/php4/libmodphp4.a
This worked fine. Then I ran gmake, and it works until the following...
gcc -c ...
mod_php4.c php_apache_http.h: No such file or directory
I realize the mod_php4.c is unable to find the path to the include files (.h files)
How do I fix this. Is this something I need to specify in php.ini? I have tried
manuall specifying the path in the c code, but that only works until another .h file
is called...?
Thanks,
Taylor
Taylor Lewick
Unix System Administrator
Fortis Benefits
816 881 6073
"Help Wanted. Seeking Telepath..."
"You Know where to apply."
****************************************************************
Please Note
The information in this E-mail message is legally privileged
and confidential information intended only for the use of the
individual(s) named above. If you, the reader of this message,
are not the intended recipient, you are hereby notified that
you should not further disseminate, distribute, or forward this
E-mail message. If you have received this E-mail in error,
please notify the sender. Thank you
*****************************************************************
--- End Message ---
--- Begin Message ---
The PHP manual is a bit vague on what the imap_utf7 methods
expect/return: "Converts 8bit data to modified UTF-7 text."
8bit data in what encoding? iso-8859-1 I guess.
Does the modified utf-7 charset exist as such on common systems so that
I can use mb_convert_encoding() or iconv() instead? If so, what's its name?
Jan.
--- End Message ---
