https://bugzilla.novell.com/show_bug.cgi?id=646935
https://bugzilla.novell.com/show_bug.cgi?id=646935#c2 --- Comment #2 from Jonathan Pryor <[email protected]> 2010-10-21 16:22:55 UTC --- The fundamental problem here is _reducing_ the amount of "mental mapping" that needs to be done. The resource directories you can use are largely fixed, so we could reasonably PascalCase the Resource.* entries, but this would introduce a "mental mismatch": the directory would be e.g. 'raw' but you'd have 'Resource.Raw' (lowercase -> PascalCase). Repeat for ~everything else. Things get worse at the "3rd level": you add the file 'raw\my_file.dat', and it would become Resource.Raw.MyFile, requiring a "mental mapping" from MyFile to the file my_file.dat, as opposed to the current ~direct mapping of Resource.raw.my_file. Yes, the current approach is ugly, but at least it's direct and doesn't introduce these "unchangeable renames". Furthermore, this could introduce aliasing issues for strings, as PascalCased string entries are perfectly valid; consider the following Resources\values\strings.xml fragment: <resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> <string name="HelloWorld">Hello!</string> <string name="hello_world"><b>Hello, <i>World!</i></b></string> </resources> PascalCasing things as you suggest would result in the same string -- HelloWorld -- being valid for two separate entries. I currently think that we should resour...@string to Resource.strings, at minimum, as needing to escape keywords is downright annoying. Beyond that, though, I'm less than convinced. I could be convinced to provide some renaming for 2nd level entries (your Expected Results entry (1)), but (as above) I think this generates a "mismatch" between the resource names and the filesystem. I'm not at all convinced that we should PascalCase the 3rd level entries, especially considering the string situation. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
