Page 2 of 2

Posted: Sun Nov 27, 2005 6:18 pm
by Roja
foobar wrote:If I were you, I wouldn't use ini's. Parsing them is slower compared to regular PHP variables. And they aren't very flexible; no escaping, value type constrained to numbers and simple strings, can't use other variables in your language string, etc. I use a regular php file for language strings, all packed nicely within a $lang[] array.
Very interesting.

I just made the switch from a file of ~ 2,000 php variables to an ini file. The parsing was faster with the ini file. We do have escaping ("Webmaster\'s ship" works fine), although maybe you meant some other form of escaping?

The other items you list, limiting value types and not using variables in the strings were things we actually wanted - by not having variables, we simply the job for translators, and by limiting types, we reduced the threat of those variables.

Posted: Sun Nov 27, 2005 11:30 pm
by GameMusic
What method do you use to parse? Do you have any theories about why it's faster?

Posted: Mon Nov 28, 2005 2:18 pm
by Ambush Commander
Actually, there's a similar discussion going on in the Settings thread, except it's about ini files versus dbs.

Posted: Mon Nov 28, 2005 2:26 pm
by foobar
Roja wrote:
foobar wrote:If I were you, I wouldn't use ini's. Parsing them is slower compared to regular PHP variables. And they aren't very flexible; no escaping, value type constrained to numbers and simple strings, can't use other variables in your language string, etc. I use a regular php file for language strings, all packed nicely within a $lang[] array.
Very interesting.

I just made the switch from a file of ~ 2,000 php variables to an ini file. The parsing was faster with the ini file. We do have escaping ("Webmaster\'s ship" works fine), although maybe you meant some other form of escaping?
That's interesting. I read somewhere, probably the PHP Manual, that variables were a lot faster than an ini file. As regards escaping, there was an issue with having somestring = "the same "quotes" embedded within other quotes". The example threw errors on my setup.
Roja wrote: The other items you list, limiting value types and not using variables in the strings were things we actually wanted - by not having variables, we simply the job for translators, and by limiting types, we reduced the threat of those variables.
It's a tradeoff. In some of my language strings, I used config variables from time to time, such as telling the user how much time he had left before the session would expire, etc. It's easier to translate, but less comfortable to use. Also, I just despise ini's after some unpleasant experiences on Windoze with locking files (which isn't possible).

Posted: Mon Nov 28, 2005 2:30 pm
by Ambush Commander
foobar, I'd like to ask you a question: how do you deal with BOM's in your translations when it comes to languages that require the full Unicode set, ie. translator's using the wrong editors and extra characters being added before <?php

Posted: Tue Nov 29, 2005 9:49 pm
by alex.barylski
foobar wrote:
Roja wrote:
foobar wrote:If I were you, I wouldn't use ini's. Parsing them is slower compared to regular PHP variables. And they aren't very flexible; no escaping, value type constrained to numbers and simple strings, can't use other variables in your language string, etc. I use a regular php file for language strings, all packed nicely within a $lang[] array.
Very interesting.

I just made the switch from a file of ~ 2,000 php variables to an ini file. The parsing was faster with the ini file. We do have escaping ("Webmaster\'s ship" works fine), although maybe you meant some other form of escaping?
That's interesting. I read somewhere, probably the PHP Manual, that variables were a lot faster than an ini file. As regards escaping, there was an issue with having somestring = "the same "quotes" embedded within other quotes". The example threw errors on my setup.
Roja wrote: The other items you list, limiting value types and not using variables in the strings were things we actually wanted - by not having variables, we simply the job for translators, and by limiting types, we reduced the threat of those variables.
It's a tradeoff. In some of my language strings, I used config variables from time to time, such as telling the user how much time he had left before the session would expire, etc. It's easier to translate, but less comfortable to use. Also, I just despise ini's after some unpleasant experiences on Windoze with locking files (which isn't possible).
http://ca.php.net/manual/en/function.flock.php...

Says nothing about all versions of Windows...just antiquated versions like 98...

This might be quite late ...

Posted: Fri Dec 02, 2005 2:30 pm
by GRemm
anyone think of using the http://www.perl.com/pub/a/2002/10/22/phrasebook.html phrasebook pattern to tackle this internationalization thing?



If you think of the encoding and charsets in a page as a language construct we can even go so far as to templatize that portion of the html as well - although I think this would be better suited to ip2locale and a good template system / structure.

http://cpan.uwinnipeg.ca/htdocs/Class-P ... ebook.html
http://www.phpclasses.org/browse/package/1248.html
http://www.google.com/search?hl=en&q=ph ... gle+Search

Posted: Fri Dec 02, 2005 3:01 pm
by foobar
Hockey wrote: Says nothing about all versions of Windows...just antiquated versions like 98...
Shame I have WinMe on my machine... :oops:
Ambush Commander wrote:foobar, I'd like to ask you a question: how do you deal with BOM's in your translations when it comes to languages that require the full Unicode set, ie. translator's using the wrong editors and extra characters being added before
I don't. Screw Unicode :P . I never thought about it, but I'm sure there's a workaround.

Posted: Fri Dec 02, 2005 3:04 pm
by Ambush Commander
PhraseBook... nice name. I think I'll use it (just for sounding pretty).

Using XML to persist it, however, I think, in my humble opinion, is a matter of preference.

Posted: Fri Dec 02, 2005 4:10 pm
by GRemm
For sure the XML persistence layer is a matter of preference. It does seem to me to be the sort of thing that XML is well suited for.

Posted: Sat Dec 03, 2005 12:11 pm
by Ambush Commander
I don't. Screw Unicode
And you call yourself an internationalizer! :P
For sure the XML persistence layer is a matter of preference. It does seem to me to be the sort of thing that XML is well suited for.
Anyone have statistics on how fast XML is compared to ini's and PHP pages?