[development] 4.8/5.0: Modules, the install system, and directories

[Khalid B]

On 2/22/06, Morbus Iff <morbus at 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).