Quoting Chris Little :
Okay. While I find the arguments in favor of localizing all string
fields in .confs entirely unconvincing, it doesn't drastically harm
anything to permit module makers to add more data to their .conf files.
That's true.
So I think we can go with the suggestion of suf
Peter von Kaehne wrote:
Chris Little wrote:
I suspected there would be disagreement with my suggested number, but I
had assumed that it would seem too low. So... some of my reasoning:
Many Bibles will include a year, which eats up 4 characters in itself.
Bibles with standard abbreviations are
Chris Little wrote:
>
>
> DM Smith wrote:
>> Chris,
>>
>> I would like to lobby for a separator between the language code and
>> the field name. I don't much care whether it is a prefix or suffix.
>> While I understand that you are suggesting that we don't have a deAbbr
>> or xxAbbr, I could see
DM Smith wrote:
Chris,
I would like to lobby for a separator between the language code and the
field name. I don't much care whether it is a prefix or suffix. While I
understand that you are suggesting that we don't have a deAbbr or
xxAbbr, I could see that it might be added some time in th
Chris Little wrote:
>
>
> Tom Cornell wrote:
>> On Wed, Dec 17, 2008 at 3:04 AM, Chris Little
>> wrote:
>>> My recommendation was actually that the default be the language of the
>>> module (what I have referred to, perhaps somewhat confusingly, as the
>>> localized name). In the absence of that
Tom Cornell wrote:
On Wed, Dec 17, 2008 at 3:04 AM, Chris Little wrote:
My recommendation was actually that the default be the language of the
module (what I have referred to, perhaps somewhat confusingly, as the
localized name). In the absence of that, I recommended using the English.
For ol
DM Smith wrote:
> Chris,
>
> I would like to lobby for a separator between the language code and the
> field name. I don't much care whether it is a prefix or suffix. While I
> understand that you are suggesting that we don't have a deAbbr or
> xxAbbr, I could see that it might be added some time
Hi,
On Wed, Dec 17, 2008 at 9:22 PM, DM Smith wrote:
> Chris,
>
> I would like to lobby for a separator between the language code and the
> field name. I don't much care whether it is a prefix or suffix. While I
> understand that you are suggesting that we don't have a deAbbr or xxAbbr, I
> coul
DM Smith wrote:
>
> On Dec 17, 2008, at 4:04 AM, Peter von Kaehne wrote:
>
>>
>> I think an argument could be had for following scheme combining both
>> proposals into following:
>>
>> [Config_entry]_original
>>
>> [Config_entry] [locale] and ubiquitous installation of a English locale
>> which i
On Dec 17, 2008, at 4:04 AM, Peter von Kaehne wrote:
I think an argument could be had for following scheme combining both
proposals into following:
[Config_entry]_original
[Config_entry] [locale] and ubiquitous installation of a English
locale
which in turn would be returned by the machin
Chris,
I would like to lobby for a separator between the language code and
the field name. I don't much care whether it is a prefix or suffix.
While I understand that you are suggesting that we don't have a deAbbr
or xxAbbr, I could see that it might be added some time in the future
and w
Chris,
I wholeheartedly concur. Description should be the actual title of the
work. There are probably are exceptions.
DM
On Dec 17, 2008, at 2:44 AM, Chris Little wrote:
Peter von Kaehne wrote:
Chris Little wrote:
Could you describe how you think all of these values would be used
practi
On Wed, Dec 17, 2008 at 3:04 AM, Chris Little wrote:
> My recommendation was actually that the default be the language of the
> module (what I have referred to, perhaps somewhat confusingly, as the
> localized name). In the absence of that, I recommended using the English.
> For old (all existing)
This discussion is repeating some of the earlier discussion about this
same subject. I repeat one point here:
"FinPR" is meaningless to Finnish people. It is customary to reference
the translation with "KR 1938" or something like that. "Pyhä Raamattu
kirkolliskokouksen 1998 käyttöönottaman
Chris Little wrote:
> Since new module .confs would have module name information in the
> module's own locale (provided it is available), I don't believe there's
> really a case where the system/user locale would ever be used.
I can see many cases - where someone wants to keep a different
language
Chris Little wrote:
Daniel Owens wrote:
- The default should not necessarily be English. This is what Chris is
suggesting. The default display ought to be in the language that the
module developer decides (usually the language of that module, except
in the case of ancient texts, in which case
Daniel Owens wrote:
- The default should not necessarily be English. This is what Chris is
suggesting. The default display ought to be in the language that the
module developer decides (usually the language of that module, except in
the case of ancient texts, in which case probably English shou
Peter von Kaehne wrote:
Chris Little wrote:
Could you describe how you think all of these values would be used
practically?
You would basically access them via the set locale.
The preference would be to get a locale appropriate name and if not the
fall back solution which would be English.
Peter von Kaehne writes:
> The preference would be to get a locale appropriate name and if not
> the fall back solution which would be English. This is how Gnome does
> the menus and it works well.
The obvious general implementation is for mod->getConfigEntry(entry) to
return the value for entry+
This is a good issue to discuss. I think both Chris and Peter's ideas
have merit.
- It would be nice to have more than one alternative, tied either to
the current locale or to some configuration option (it is up to the
front-end developer, if you ask me, how they use this information)
- The d
Chris Little wrote:
> Could you describe how you think all of these values would be used
> practically?
You would basically access them via the set locale.
The preference would be to get a locale appropriate name and if not the
fall back solution which would be English. This is how Gnome does th
Peter von Kaehne wrote:
Chris Little wrote:
In addition to these, I recommend adding enDescription, enAbout, Abbr,
and enAbbr.
We traditionally include English and localized title/about data within
Description & About entries. The addition of enDescription and enAbout
would simply divide thes
Chris Little wrote:
>
> In addition to these, I recommend adding enDescription, enAbout, Abbr,
> and enAbbr.
>
> We traditionally include English and localized title/about data within
> Description & About entries. The addition of enDescription and enAbout
> would simply divide these, so enDescrip
Jonathan Morgan wrote:
On Thu, Aug 14, 2008 at 4:50 AM, Ben Morgan wrote:
I'd really like to see an abbreviations field - while a description is
useful, an abbreviation such as KJV, ESV, etc is invaluable when there is
not much room.
Most bibles have such an abbreviation.
I also agree that we
On Thu, Aug 14, 2008 at 4:50 AM, Ben Morgan <[EMAIL PROTECTED]> wrote:
> I'd really like to see an abbreviations field - while a description is
> useful, an abbreviation such as KJV, ESV, etc is invaluable when there is
> not much room.
> Most bibles have such an abbreviation.
> I also agree that w
25 matches
Mail list logo
