User-Friendly Quich Update
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
#442 User-Friendly Quich Update
I
I would restrict the shown tags either to those that exist
in the Gedcom (not good for a new Gedcom) or to a
configurable list (the same list could be used in the Edit
Interface and in the Calendar).
I do not want to show for instance Adult Christening for
my Gedcom and others do not want to show Bar
Mitzvah.
Perhaps this could be made by defining profiles (at least
Christian, Jewish, LDS) that the user could define in his
profile and change on the form by a radio-button.
The lists should also contain Custom Events and Facts.
II
It should be possible to add an Attribute Descriptor for
Facts.
III
It should be possible to fill the dates in the page
language, perhaps in format "Between 31 7 1945 And 15
9 1950", "Interpreted 15/9/2000" (any delimeter), "Circa
August 1960" or "13. kesäkuuta 2004". PGV should
create from this the Gedcom date format.
It should also be possible to fill "About 25 Kislev 5703".
Numeric months are no good at least in Hebrew.
Currently PGV translates 3/4/2005 to 4 Mar 2005.
The date format should be DD/MM/YYYY and this
format should be highlighted on the page.
At least the English August 13, 2004, 13 August 2004,
August 13 2005, AUG 13 2005 and 8/13/2004 are
already supported.
Logged In: YES
user_id=300048
This report has many RFEs in one which make it difficult to follow
and complete them.
I have just submitted a completely new quick update form to the
future branch of the CVS. In this version of the update form:
1. All data is filled in the form
2. You can set which gedcom tags will be shown on the form in
the gedcom configuration. (Custom EVEN and FACT tags are
not yet supported but will be.)
3. Tabs have been added for family information
4. It is possible to add/change/remove people in families
5. _HEB names are supported if RTL processing is enabled.
In your list above:
#I is completed except for the custom facts.
#II I'm not sure what you mean by this one.
#III - The dates are only translated if they can be recognized by
the javascript date function. I do not want to prevent people from
being able to enter anything they want in the date field. I also do
not want to try to figure out how to parse out any type of strange
date formats and dates in other languages. Extending the date
support beyond what it currently is would require lists of all
possible months in different calendar types, conversion tables,
and symantec text processing. I consider work in this to be
research worthy, meaning that people are doing it for master's
thesis and doctoral dissertations. It would also require thousands
of lines of code to do what may seem quite simple, but which is
actually very complicated. So, at this point, with the current
technology available, I think it is better to let the administrator be
smart enough to fix the dates if they are entered incorrectly, then
to try to make the computer do it and do it poorly. So to sum up,
date conversion is supported to the extent that it is currently
supported in javascript technology.
--John
Logged In: YES
user_id=634811
Please open a new RFE for any items that are not done.