Allow differently capitalized aliases for Case Sensitive case matching
Howdy.
I'm working on putting some Invisible Sun stuff into Realm Works. In that game, the eight (no, nine) realms are classified by colors: The Indigo Sun, the Blue Sun, the Green Sun, the Gold Sun, etc. Colloquially, they are "the Blue," "the Green," "the Gold," etc. Ideally, I could input two identically spelled but differently capitalized names, with Sensitive name matching, and save myself the headache of every single color reference popping up. Public Name: Green Sun (case matching Auto Correct) Other Name: The Green (case matching Sensitive) Other Name: the Green (case matching Sensitive) Thanks! |
So, in the NAMES part of the topic, set the matching to case sensitive.
|
Sadly, in my experience, the name list duplicate check for a Topic is case-insensitive regardless of whether the individual names are case-sensitive.
|
I would be very opposed to different capitalization forms being different names.
As an example in my SF realm I have the "Alderson Jump Drive," with "Alderson Drive" as an alternate name, as the name of the topic that describes the device. The device is referred to, in various other entries, as the Alderson jump drive, The Alderson Drive and the Alderson drive. I also do things like this all over my Pathfinder realm but I was just working on the SF one so it came to mind first. |
Quote:
Quote:
|
Quote:
If AB is distinct from ab and Ab and aB then you would absolutely have to include three as alternate names of one. I would find that incredibly unpleasant, and it would break dozens of existing links. |
Quote:
Otherwise, could you add a question into the OP so that we know for what you asking help with. |
There are more than a thousand spells and magic items in Invisible Sun. Each of them has a color associated with them. This is formatted as:
GOETIC’S MAT Level: 3 Form: Woven cloth mat with a protective circle stitched into it This functions as a protective circle, but takes only an action to unroll and put into place. Object Depletion: — Color: Invisible Thus, for every instance of Invisible, Green, Blue, etc., I have to ignore on auto-detect. If I could tell Realm Works to recognize "the Green," I would never capture "Green" at the start of a sentence when used as an adjective, which is good. But I would also never capture "The Green" at the start of a sentence, which is bad. |
I see the problem now. You want to use the CSV tool to import a shed load of spells and magic items, 99+% of which will never get used or linked to, and turn on auto accept to save time on the linking after doing so.
I strongly do not want this change as it would literally break my main realm and any future realms would be made incredibly and unpleasantly tedious to set up. |
I fail to see how this would break or complicate anything, but I don't know how to explain it differently.
|
I already explained this.
If AB is a topic name and ab, Ab and aB are distinct names then anyone who creates a topic that might use any of those forms has to create those all as alternative names and going forward after such a change was made any new use of existing names where users are used to mixing capitalizations without issue would have issues. |
1 Attachment(s)
Quote:
Once you enter "AB"... "Ab", "aB", and "ab" are not allowed as additional aliases. They are seen as duplicates of "AB" and the "ok" button remains disabled until all such "duplicates" are removed. (see attached image) Perhaps it is a bug that has not been recognized as one before? |
Quote:
|
Quote:
|
Quote:
|
Quote:
If that isn't your proposal, it is literally the name of your proposal, then explain WTF you actually want. |
Quote:
2. From my original post. Quote:
|
Quote:
But making them into distinct names breaks my realms, and I'm sure a lot of others. |
Quote:
|
Create a topic, name it "Green," open Manage Names, set "Green" Case Matching to sensitive. Create another topic named _anything but Green_, use Green and green in snippets. Only "Green" will be found to be a valid name to link.
First image Second image |
Quote:
|
Quote:
|
Quote:
His explanation makes sense to me. He is avoiding having a topic called only "green" because it will cause too many links. |
Yup.. in my case, it is not colors, but titles that can have different meanings in different organizations. Regardless, at least some of us have use for this.
|
?
I use things with the same name all over the place. That isn't a problem. If he wants to use auto-accept based on capitalization I simply have to say that auto-accept is almost always a bad idea. What he wants breaks my realm and breaks how I do things. I still remain unalterably opposed to this. |
It could be a setting you have to enable globally so kbs would be ok. That makes everyone happy. I would like it too. PF2 capitalizes or italicizes rules elements to keep things like lock from linking all the time if we had this option plus an option to require a particular font element to be an auto key
|
Quote:
This approach would be very useful for me. |
Quote:
|
Quote:
|
But... But it only comes into play when a person is using the Case Sensitive setting on an alias. Instead of *only* being allowed to detect *one* combination of case sensitivity, this feature would allow you to detect variations of capitalization.
I cannot fathom how this breaks anything. Would you kindly walk me through a specific, exact situation where this change would negatively affect your realm? Not an "ab vs. Ab vs. AB" hypothetical. Something real. Because for the life of me, all I can figure is that you're violently opposed to something I'm not suggesting. |
I explained it in real terms and I've explained it simply. I do not know what else to say to make it clear to you.
|
Quote:
Topic name: Alderson Jump Drive (case matching: None) Alternate name: Alderson Drive (case mstching: None) Possible alternate name: The Alderson Drive (case matching: None) These two names would capture every instance you've outlined. My proposed change would have zero effect on this topic. |
!
Yes, it would! I do not understand why this is so hard to make clear. Your proposal is that every capitalization form of any string be a distinct name. That means that ignoring case would no longer possible, at all! AB would not match ab ever under any circumstance. They are separate names! To make my existing topic work, and that is just one example, would need at minimum 2 additional aliases. Which would require me, and every other person affected to go back through and add those aliases to every topic with no idea which are affected and which are not until something fails to link. And lord help the people who have case matching set to auto correct. Just so you can use auto accept, no thanks. |
That... is not my proposal.
My proposal is to let a name with Case Matching set to Sensitive be distinct from another identically spelled but differently capitalized name with Case Matching also set to Sensitive. A name with case matching set to None would still find every capitalization variant. |
Ok, let's take a step back.
Currently, I can create multiple topics and give them same alias, with different capitalizations or the same capitalizations: Topic 1 Main Name: "Topic 1", case-insensitive. Topic 1 Alias: "Topic One", case-sensitive Topic 1 Alias: "Topic 2", case-sensitive. Topic 2 Main Name: "Topic 2", case-sensitive. Topic 2 Alias: "Topic Two", case-insensitive Topic 3 Main Name: "Topic 1", case-insensitive. Topic 3 Alias: "Topic One", case-sensitive The GUI will warn me that I am re-using a name without a suffix to differentiate, but one of the options is "Save anyway" (amounting to a response of 'I understand, do it anyway'). This will cause the the GUI to stop and request that I select which Topic text of "Topic 2" should link to, as there are two match candidates. Likewise, text of "Topic 1" would present two possible matches. What I cannot do is this: Topic 1 Main Name: "Topic One" , case-sensitive Topic 1 Alias: "Topic one", case-sensitive. <-- THIS IS NOT ALLOWED Regardless of the case sensitivity settings, the alias is seen as a case-insensitive duplicate of the main name. Because these aliases CAN be created across topics, I cannot see how honoring the case sensitivity of the aliases breaks anything in any way that is not already "broken" by allowing the aliases to exist on what amounts to the wrong topic. The only effect I can foresee is that there may be an additional match candidate suggested for certain text (which is exactly what I want). |
Each topic title and alias is a name. Names can point to multiple topics. Having the same name twice in one topic makes no sense.
What the op wants, and I'll repeat I've never ever seen a time where this is a good idea, is to create a topic with a common name and then use auto accept so he can do a mass import and not have to spend any time at the keyboard during the linking process. I'm starting to wish that tool had never been created. It has resulted in multiple requests for features that would make life harder for people who enter their own data by hand. |
Quote:
|
Having two different case sensitive names in a topic makes sense when a topic name may be capitalized in some instances and not capitalized in others. Take, for instance, these examples:
1. The Green is renowned for its abundant, explosive life. 2. Settlements are hard to find in the Green, because whole forests may spring forth from the ground overnight. Linked topic name: Green Sun Linked topic alternate name: The Green (case sensitive) This name combination will capture example 1, but not example 2. If I add "the Green" (case sensitive), in an effort to capture examples 1 and 2, the OK button is grayed out. Also, I'm not using an import tool. I'm copy-pasting from a PDF. And this isn't about auto-accepting links; it's about preventing false positives. Silveras, thank you for understanding and explaining my meaning. |
Quote:
If you were not doing a mass import then this wouldn't be an issue. Clicking ok few times per article is nothing. |
I guess I'm dense.
Sounds to me like you have a couple of scenarios. 1. article named 'Green Sun' with an unspecified number of aliases with the word 'Green' in the alias name fields. Then you could have other articles use either the main name or the aliases to link back to the main article. 2 you have several different articles that contain the word 'green', 'Green', 'gReen', etc that are supposed to be different articles with different aliases and you don't want those to become interlinked. if it's the first case, I don't see a need for this. If it is the second case, I'd find this highly confusing and a pain to remember what linked where or when and I don't think you or anyone would want to have auto-linking turned on at all in this case. Also, I wouldn't want to import a realm like that into my version of realmworks, even if it was distributed free of charge (provided it isn't violating any copyright or Intellectual Property issues). In my opinion, it would be more useful to put some kind of descriptor in the name or alias field that makes it clear what it is. 'Green Sun (organization)', 'Green Sun (leader)', 'Green Sun (war master)', 'Green Sun (economist)', 'Green Sun (weapons)', 'Green Sun (ships)', etc. I also suppose this could be more of an organizational issue then a naming issue. 'Green Sun' should probably then be at the top of the article hierarchy with nested sub-articles breaking down the information. As an example you could have 'Green Sun personal equipment' and then under that hierarchical branch you would have 'firearms', 'melee weapons', 'armor', 'uniforms', 'communications', etc. In this case, I wouldn't want the words 'green' or 'sun' in any case to link except as a full field matches with or without case sensitivity. So, by the examples given, I'd probably have to come down on KB666's side. Mostly because I can see this becoming so convoluted and confusing as to make the entire work useless. |
All times are GMT -8. The time now is 12:58 PM. |
Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.