On Mar 5, 2006, at 10:30 PM, Daniel Swarbrick wrote:
> bkml wrote:
>>
>> On Mar 6, 2006, at 4:26 AM, Peter Nixon wrote:
>>
>>> I'm with Daniel on this one. We most definitely should use the
>>> correct,
>>> internationally accepted codes. To do anything is is simply
>>> insanity.
>>
>> I didn't say we shouldn't use them.
>>
>> The issue is about which abstraction layer should use technical
>> terms,
>> and which abstraction layer should use plain language.
>
> So, given your examples of "US-English" and "JP-Nihongo", why are you
> using an ISO 3166-1 country code, but not an ISO 639-1 language code?
> Surely "JP" is just as ambiguous to us dumb humans as "JA" would be
> for
> the language.
>
> JP-Japanese, or JP-Nihongo?
> RU-Russian, or RU-Russkiy? (or even "Russkiy" written in Cyrillic,
> which
> I won't type here, because believe it or not, not all mail readers
> will
> handle Unicode. How's that for a crazy idea?)
--- SNIP ---
>
> I really, really strongly advise against throwing Unicode into the mix
> at this stage. Use Unicode in your GUIs if you like. But use
> recognised
> standards like ISO 3166-1 and ISO 639-1 internally. It will save you a
> lot of headaches.
I've kept rather quiet on this whole issue on the list as I'm pretty
limited on what I can do these days,
However, Straying from the ISO codes is just a bad Idea. There is a
reason ISO stands for International Standards Organization.
Will users ever see this stuff possibly, is the goal to insulate the
users from this in an Internationalized GUI? Yes
so whats the problem? Stick with UTF-8 on the backend and translate
it on front end... More Problems for the user? possibly... but if the
backend to front end APIs are clearly defined, whats the problem.
Once a CLEAR API layer is established people
( {$SOME_COCOA_PROGRAMMER}, {$SOME_PERL_PROGRAMMER}, and
{$SOME_dotNET_PROGRAMMER} ) can then proceed to do whatever they
want. Not to mention it would lend itself toward us having things
like a CLI thats curses based where we can update extensions etc from
the CLI not just by editing the config files and reloading the system.
I have not had to work on a PBX where I couldn't pull up some curses
interface on a dumb term or telnet session and do what I needed to do
(atleast til I came to asterisk or it was welll over a decade ago).
Now that being said, .ini files, xml files, plists, csv's or whatever
on the backend would not matter, the GUI would not directly TOUCH
said information but make an API call to the BACKEND to save/retrieve
said data. Not to mention at that point the config files dont need to
be user readable, only "technician" or "coder" readable.
just my 2 cents (in USD which is rapidly loosing value)
K
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
