Ask HN: How does you team name string resource ids?
What's your approach to organizing and naming the localization string identifiers?
Here are our thoughts so far:
It could make sense to name resources by content, maybe hinting at the kind of usage via prefix. So we may have labelOK = "OK", messageFileTooLarge = "The file exceeds the maximum file size.", and labelZipCode = "Zip code".
Naming by content has the advantage of handling format arguments naturally: The resource messageFileHas_0_MBWhileMaximumIs_1_MB clearly takes two formatting arguments, the actual file size and the maximum file size.
If we allow duplicates to allow for fine grained translations however, naming by content alone doesn't make sense. In order to get unique resource names, we must somehow include the place of usage in the resource name. That works for graphical controls, although the identifiers tend to get a bit long: fileSelectionConfirmationButtonText = "OK", customerDetailsTableColumnZipCode = "Zip Code". However, for non-visual code files, it gets harder. How do you name a specific usage of a string if you don't know where it will eventually be displayed? By code file and function name? Seems rather clumsy and brittle to me.
I crossposted this question from my colleagues post on programmer's exchange: http://programmers.stackexchange.com/questions/326369/how-to-organize-localization-string-resources
0 comments
[ 3.0 ms ] story [ 12.3 ms ] threadNo comments yet.