https://bugzilla.wikimedia.org/show_bug.cgi?id=26786
--- Comment #17 from Happy-melon <[email protected]> 2011-05-04 23:06:00 UTC --- > (In reply to comment #13) > It would be easy to fix the code so that the first parameter could be *either* > a style type *or* a work type like "book," "web," etc. If the latter, then the > default style is used. I haven't looked at any of this code in detail, but this is a fundamentally bad idea, and the first reason is 'localisation'. "title", "url", "MLA", "Chicago", etc, all need to be localisable into foreign languages and foreign alphabets; you don't need to add support for that yourself, but you *do* need to design the syntax such that it can reasonably be added by someone else. "apa" is the word for "water" in Romanian. What might it be in other languages? Perhaps the word for "book" or "journal"? ;-) Equally whenever you open the doors to users adding new features, you have to open them all the way: the other watchword is "extensibility". Other than the fact that the software might get confused, why shouldn't a wiki user create a citation style called "book"? More seriously, if a user creates a citation style with a name which is *not* confusing, but a developer subsequently makes that keyword a valid citation type, a much more subtle bug is introduced. Every parameter should either be in a precisely-defined order ({{#if:<test>|<then>|<else>}} etc), or be identified by a unique keyword-and-equals-sign parameter name. Introducing 'shapeshifting' parameters, while convenient at the time, is a recipe for future problems. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
