Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
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.
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).
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
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).
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.
Hockey wrote:
Says nothing about all versions of Windows...just antiquated versions like 98...
Shame I have WinMe on my machine...
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 . I never thought about it, but I'm sure there's a workaround.