Just wondering if there are any rules for developers when it comes to case used in string identifiers in the language pack files.
I've come across a number of plugins causing local problems, because the developer found the necesity to use both upper and lower case in the string identifiers (which go to stringid field in the database).
qtype_ordering has the following identifiers:
- numberingstyleabc for lower case numbering a., b., c.
- numberingstyleABC for upper case numbering A., B., C.
- numberingstyleiii for lower case numbering i., ii., iii.
- numberingstyleIII for upper case numbering I., II., III.
A similar thing seems to be happening with qtype_musictheory
When trying to update a language pack locally, these mixed / upper case identifiers cause the tool to stop working altogether.
If there are any rules for developers, where can I find those... and more importantly: how to convince a developer to solve these issues in his/her plugins?
Apart from it being a bad idea to distinguish things just by upper/lower case, I can imagine the problem rises when you are using a file system on your server that doesn't care about capitalisation of files, like NTFS (Windows) or HSF+ (Mac).
Unix and FreeBSD file systems might not show the problem you describe, since they are case sensitive.
If that's the case, it should be filed as a bug.
Ouch, that's a good catch.
The only implemented rul I am aware of is that the string identifiers must pass the
PARAM_STRINGID validation which is currently implemented as a regex
so there are no special rules about the letter case.
Some components (such as countries.php) have all string ids in upper case, too.
I think the problem is with the way how the current (and let's admit, the obsolete) language customisation tool handles these strings ids when it loads them into the database.