New Bug and Questions?
I was helping out a patron at one of the sites, and we found (after about 30 minutes of troubleshooting) that the searching for an ancestor via their ID doesn't work because the keys, "a" "e" "i" "o" and "u" are disabled. Everywhere else on the site these keys work.
They claim that it is vital to have them use the IDs to get to the indivudual, so I was wondering two questions:
1) How do I help the patron get to these individuals while this bug is up?
2) Can the disabled keys be re-enabled?
Thank you!
Best Answer
-
@Marton Kippen, maybe I missed the point but there is no "bug". You should not have a PID with those letters in it. The PID is incorrect. You can always use Find to locate a profile in FS with the name and some vitals added. Also the person could go to My Contributions and Search by Name
6
Answers
-
Hi
It is nice to hear someone else is having this problem. i thought it was my computer. It happened quite awhile ago, and I am trying to remember what I did. Here are my suggestions:
1) Clearing cache
2) Restarting computer
I do remember it was a reoccuring problem. I haven't had the problem for quite awhile now. PaulaAnn
0 -
I never realized that ID numbers never have vowels. That was very interesting to learn.
I wonder if the original patron has written down a bunch of IDs with the number one in them and thinks they contain the letter i?
4 -
That is a likely explanation for the misread PIDs. Unlike the base 10 numerals we all use (0 1 2 3 4 5 6 7 8 9), I think the PID is actually a number in base 30 (numerals 0-9 plus 26 letters of the alphabet minus 6 letters = 30 digits) Some Data Admin could maybe give us a better explanation of the exact number scheme they use. So for example 15 in base 10 would be F in base 30. The - dash is only added for readability.
0 -
Whilst on the subject, why (apart from the fact it would reduce the number of combinations) did FamilySearch include characters that are easily confused? For example, both "S" and "5", one of which is so often mistaken for the other.
1 -
Chas Howell, it's actually numerals 1-9 (there's no 0) plus 26 letters minus the five vowels. So you're right that it is 30 possibilities, but the options are slightly different. And the letters are clearly not used in alphabetical order, so 15 is not F. Remember that Person IDs were issued starting with L for a long time, and then starting with G.
Paul W, that's a good point. The confusion between S and 5 happens frequently, and there was no good reason to include both. Having 29 vs 30 options would not have made any noticeable difference in the number of possible combinations, since the scheme is not limited to just 7 characters. With 7 characters there are 21 billion possibilities for 30 options, vs 17 billion for 29 -- not really an issue when you can move on to the hundreds of billions of possibilities with 8 characters.
1 -
The other combination that causes trouble for me is B and 8.
Computers really just work with numbers, at the most fundamental level just 0s and 1s, so it would make sense that the IDs are just a way of compressing a huge number into something that is practical to type.
It is certainly easier to type a seven character string instead of its hexadecimal equivalent.
Instead of KLMS-VZS, they could have chosen to make us stare at 4B:4C:4D:53-56:5A:53
2 -
Agreed there are several combinations of symbols that can be easily confused. But it’s not so easy to eliminate a symbol in this case because you have to have 30 symbols. For every symbol you remove you have to add a new symbol to take its place to maintain the integrity of the math. I can increment my previous PID by one and I will always get a unique number. I can’t be assured uniqueness if I generate a random string of 7 characters. Now that new symbol would have to be on everyone’s keyboard. Preferably without using a shift or key-combination.
About the apparent missing zero. This gives me pause. In any base scheme you will need a symbol for a zero place holder. One thing FS might have done is designate another letter symbol as the zero place holder. For example Z could be the place holder for the eliminated zero. I’m still pretty sure this is a base30 mathematical model but I do not know exactly how it was implemented.
Alan E Brown, (15 base10) is (F base30) in the usual case. But you are right it would not be F in base30 in this case because symbols A & E were eliminated. Instead (15 base10) would be H in this version of base30.
0 -
There's nothing special about base 30 -- the PID system is simply a way to convert a large number into a readable set of letters and digits. If the problematic pairs were eliminated (S-5, B-8, 2-Z) we would then have 27 possibilities, and base 27 math would work just fine. The only difference is that we'd run out of 7-character PIDs sooner and then move to 8-character PIDs. But given that we can have longer PIDs, the scheme will never run out of possibilities.
But this is speculative talk, and as a practical matter, I can't imagine that the PID system will be changed at all at this point. The particular IDs assigned to billions of persons and relationships need to stay the same, since people have come to rely on those specific assignments. Changing them would be a cataclysmic change that would be far worse than the few problems we have now with ambiguous readability.
Trying to outguess the algorithm for converting a large number into a PID is an interesting diversion, but has no real value. I assure you that 15 is not H in this system, since the letters/digits are not used in order. I'm pretty sure that K is followed by 2, followed by L, followed by G. But I don't have time or inclination to figure out the exact alphabet order that is used to issue the PIDs and other identifiers at FamilySearch.
2 -
Thank you all. I relooked at the PID, and found that the patron copied the PID wrong, so there was no vowels on the PID.
0
