I have an experimental version of SmartName that does this and it does not break any existing tests. I'm wondering what if any risks in having these special key values that are out of band with respect to normal name to key processing.
The other thought is that I may want to have Set definitions that match on the special key prefixes (N or JD in the examples) that are similar in pattern to the *star set, or the related *rstar.
This is pretty interesting. It does mean adding more English-specific handling to SmartName, when we had very nearly eliminated it (except for :singularize), no?
Anywhere to see that code? maybe a PR?
I really don't want add any more english-specificity to SmartName, but maybe we should look at ways to modularize?
Yeah, I can make a PR to the SmartName repo. This isn't that English related, only the day/month names, but numeric dates are all multi-lingual. Hopefully, the Date classes will give some international help on text in the month (days are only used so it can ignore them).
Once we are doing internationalized Wagn, I think a lot of this will be fairly obvious. The bottom line is that the keys don't have any language, just a number, so while the recognized names may be language specific, we can pick a default format that isn't. It isn't really quite ready yet, but reasonable for looking at the concepts.
"only the day/month names". That's more than enough, imo. And I wouldn't say that's the "bottom line". There are lots of ramifications.
For example, if I use "1 Julio" instead of 1 July, then it quickly becomes possible to have two different cards representing July 1 (Canada Day!). So then you go back later to add Spanish support to your wagn and suddenly you have key conflict.
This obviously shouldn't kill the idea, and I strongly suspect we can come up with robust solutions for handling these issues, but as far as standard wagn installations are concerned, I would not want to add any additional english-bias until a broader plan is in place.