bkml wrote: > The default on OSX is XML plists, not plaintext, because OSX users > are far less likely to edit files by hand than users on most other > platforms. On Linux and BSD users are more likely to want to edit > files manually and there is a lot of sentiment against using XML for > this reason. > > However, the framework handles different formats transparently, so > yes, XML is supported as well, but the consensus was that the > *default* should be human readable/editable as well as the point that > there should be a human readable/editable option in addition to XML > in the first place.
Personally, I don't find plaintext plists any more or less human readble/editable than XML. You still have to properly close "tags", so they're not as forgiving ini-style files. As long as the plist library supports handling both plaintext plist and XML, I'll be using XML. I thought the ultimate goal here was to have config files in a format that could be easily manipulated by a GUI... on all platforms. > The framework supports Unicode, so if we wanted to make use of it, > yes, we have that option. > > However, romanised Japanese is well understood by any Japanese below > the age of 90, JP-Nihongo is still significantly more intuitive than > jp_JP. I can't believe I'm reading this. You stand up for the use of proper English in computing, then you just totally trash thousands of years of somebody else's culture. What was that comment about OEJ wanting Japanese to be rewritten to fit Asterisk better? >> you think the average *nix shell is gonna have support for all those >> fancy character sets, and properly display language names written in >> their native script? No! > > the average shell / terminal on my system certainly does ;) Exactly... your system. How about everybody else's system? Assume that a config file contains non-latin characters to describe a language, and that file is passed to another system that only has latin character sets installed. How human readable/editable is it now? What exactly do those gibberish characters mean on a system that doesn't have full unicode support? > First, the end user GUI reads the unicode strings from the > appropriate property list. This is however besides the point because > we are talking about a file that is *intended* to be human readable/ > editable. ...assuming that all scripting languages out there that people wish to developer GUIs with actually support unicode string handling. > BTW, the example I posted was just an adhoc. It may turn out > differently, yet, whatever form it will take, the requirement for it > to be human readable/editable should be satisfied. I suggest, in order to satisfy this human readable requirement, that an ~optional~ description is used, in which you can have unicode characters. For internal system use, ease of coding, and non-requirement of linking against unicode string handling libraries, use ISO codes to designate the language. Ever heard of the KISS principle? Keep it simple, stupid! _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
