On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
http://php.net/parse_ini_file In other words, PHP has already overloaded the .ini meaning for us. Here is a way to get over the .ini stigma:
Please, please, please. This is now stop-motion.
When I had .ini hate, it was because I didn't know a) the extent of what he meant by .ini, b) that there was a parse_ini_file function already.
PHP's implementation of .ini files is correct. I've also tested it and it is actually useful.
But, the *real* problem is described herein: http://lists.drupal.org/pipermail/development/2006-February/014021.html
We don't get all the capabilities of t(). While we can certainly throw a t() around the retrieved string, we can never use %vars to include URLs or user data, or what have you. This, I think, puts the nail in the idea of help-within-an-ini file.
*That* is what should be discussed in regard to .ini not OSes. *That*, and that alone, is why I'm against .ini now.
Merely trying to lighten up the mood, not make fun or anything. What you raise is a valid concern of course. Could certain strings read from the .ini file be designated as passed to t() and hence translatable using the same mechanism we have today? (Although not ideal, that works as it is today).