Aliases (and other flexibility) in input data

[badpens]

I think I already saw some of these (e.g. category/gender aliases), but here are some other things that are good to have:

Where is there is a set of valid input values (e.g. gender, category, region), allow a case-insensitive match. That is, fEmaLE is an aliase for Female.

Aliases: Gender: F=Female; M=Male Category: Jr=Junior; YC=C=YouthC='Youth C'=Youth-C; (notice the ) USAC#: none=n/a=na=no= Region: =... (just the region numbre)

When matching an EventClimber input to Climber

• allow case insensitive match
• firstname match if first word matches, but one value has a second word (e.g. if eventclimber data from the facility includes middle name, while USAC db does not) In the above cases, the USAC/Climber info should be favored over the EventClimber info.

[jsnyders]

On import of master list of climbers or event climbers gender, category, and region are all case insenstive. Gender allows f or m Category allows youth[- ]?[a-d], junior, jr, open, adult, master, masters, [a-d] Region allows just the region number (e.g. 401) or any substring of the full name as long as it is unique. for example "heart" matches "401 (Heartland)" USAC# must be blank When matching by first and last name the match is case insensitive Currently master climber data always fabored over event climber info

So I believe the import parsing is very flexible. The only cases above that are not handled are

• YC for Youth-C
• n/a etc. for USAC#
• ignore potential middle name in first name field I'll close this general issue and if any of the above become pain points in practice we can open a specific issue.