Decapitalization of Content

[msprijatelj]

Beginning with massif-press/lancer-data#173, there has been a push to change the naming conventions of LCP items to use a "Capitalized" convention instead of an "ALL CAPS" convention. The rationale is that a Capitalized convention better preserves the style of the official Massif books, in many instances, and would allow users of the data to choose between the the conventions of the books and the conventions of the Comp/Con website. It could also contribute to better readability of statblocks and printed character sheets.

Right now, Lancer Data has "decapitalized" Mech Weapons, Systems, and Mods, Pilot Backgrounds and Gear. The Long Rim data, Wallflower data, and KTB data all have similar PRs awaiting review. However, I'd like to go a step beyond Mech and Pilot gear and also decapitalize Frame Traits, Talents, Core Bonuses, and even Skill Triggers. These are in fuzzier territory since they are actually in all caps as headers in the core rulebooks, but the vast majority of cases have clear "decapitalizations". An example of these changes within a mech statblock can be seen in this post.

Right now, the content in lancer-data with names still in all caps (and lacking a PR to change that) are as follows:

• Actions: Inconsistent in their Comp/Con naming conventions; some are Capitalized and others are ALLCAPS
• Frames: Changing the logic for these threatens the integrity of the licenses, since many licenses are still constructed via Frame Name. That said, the implementation of the license_id field may smooth transition from a Name-centric License organization to an ID-centric one.
• Glossary Entries
• Manufacturers: This may or may not affect functionality; needs to be checked
• Skill Triggers: The one place in the book that uses them in a character-building context is "Creation Example", pp. 36-37, where they are formatted like sentences ("Read a situation") instead of Capitalized ("Read a Situation")
• Statuses: These lack an ID, meaning that any 3rd-party material referencing them by name may break if the names are changed.
• Tags: These are consistently all-caps, but they have IDs for reference and may be safe to decapitalize

Any thoughts on whether it's worthwhile to convert these to Capitalized case? I feel that Skill Triggers, Glossary Entries, and Manufacturers may be relatively painless, but I'm curious on others' takes. I know that some homebrewers have been struggling with the partial implementation of Capitalized vs. ALLCAPS, so I'd like to hear their takes, if possible.

[Kuenaimaku]

In my opinion, the point of data is to be just that- data. Information about everything (for LANCER, whose main language is English) should be written in the most natural English possible. The display of that data should be up to whatever decides to leverage that data. To compare it to COMP/CON, the app itself should determine what should be all uppercase, what should be capitalized, and what should essentially be just display the data as-is.

To achieve this, the implementation of license_id should be expanded to every kind of object possible to ensure that there's no need for sanitation in the sense of case-sensitivity. I understand that going back and saying that IDs are required now is painful for existing content (and existing third party content as well), but I feel like this allows for the least amount of collision between sources.

[TheFwuffernaut]

I'd be careful with Manufacturers.
I already made a request last year with regards to untying GMS from LL0 that was (in theory) opened in August 2020 when the initial TODO note was made - and if I had to guess there's something in there that'll break if you change it seeing as it was summarily dropped even after I went through every reference I could see with regards to it (even talked with you and beef over it during :') ).

As for the rest of it, I see issues cropping up with implementing this for frames, with the end result being people having to manually fix/remake every pilot like with the Wallflower Pt 2 > KTB LCP transition.
Currently there's no smooth way for CC to put in what it roughly thinks is right based on the item, so I don't think it'd be feasible to completely retire that system immediately without some bolt-on to convert it from name>id check and make sure its the right one.

Like, this is the same CC that doesn't like you changing the description field of an lcp_manifest even if the rest of the content is the same (duplicates the LCP), and also doesn't properly refresh frame traits etc. if a frame is updated within an LCP and everything is kept the same outside the relevant frame traits (see posts I've made in compcon-homebrew in the discord, namely this message).

Overall I'd like this to be implemented, but I think you should start purely with what works. Save the rest for a later update and take your time with manufacturers and frames because they seem a lot like a jenga tower atm to me with the potential to brick a load of user data on all fronts outside of purely core content.