* Change source template

[JoopvB]

Attached is a plugin that changes the template of selected sources from A to B.

The user selects A and B and is the shown a mapping window to specify which field of A goes to which field of B. When all fields have been mapped, the user selects the sources to change and the plugin will make the requested changes.

If A contains fields that are not in B, the plugin will display a message and ask the user whether to proceed or not.

The plugin can also be used to swap fields, e.g. a template A has 2 person fields, p1 and p2. Selection of A as the old and new template, mapping p1 to p2 and vv will do the job.

I've allowed that name fields (NM) can be mapped to text fields (TX) and vv. All other fields require the same type to be mapped.

I'd appreciate testing and feedback before uploading of the plugin to the store. Thanks!

Edited to add: plugin superseded by a later version.

[ColeValleyGirl]

Joop, apologies for the delay in testing this.

I haven't tested exhaustively, but what I've tested seems fine.

One comment: it isn't possible to map all old fields to new fields because of the constraint by field type. I wonder if it might be useful to relax that -- so for example an AD field could map to to a TX field? (In fact many things could map to a TX field.) That could result is less data loss, perhaps?

[JoopvB]

Helen, thanks for testing.

Indeed a lot of fields could be mapped to TX but I thought it wise to be restrictive to prevent errors. Also I couldn't think of a situation where one wants to map Places, Addresses or URL's to a text field. The only exception (in my personal experience) is the mapping of TX to NM (the field was meant to be a for names in the first place). Also the mapping of NM to TX seemed of use.
An example when people are moving: Family Holmes, with Sherlock and Watson moved to Baker Street 221b. If the template started out with a NM field, the user might decide to change it to TX to accommodate Sherlock.

What do you say: upload it to the store and wait for people to request more mappings?

P.S. Did you also try the change to the same template to swap fields?

[ColeValleyGirl]

Joop,

an example I was thinking of is AD-Address to TX-Church.

I hadn't tried changing the same template to swap fields... but I have now.

Before putting it in the Plugin Store, do you want to think about including a Help button using fhUtils?

[AdrianBruce]

... Also I couldn't think of a situation where one wants to map Places, Addresses or URL's to a text field. ...

What if I had a template that used a place or address but I wanted to produce my version that allowed what is normally the address to be the name of a ship or something? I'm thinking of censuses where the location is a canal boat.

This may not be important because I don't know what the implications of something being a place are, but I thought I'd throw it in, in case it helps. Or not.

[JoopvB]

Help button, good idea, I'll add it. And yes, I now understand why you specifically used AD as an example (I don't use addresses myself so it's not really top of mind). I'll add that too.

[JoopvB]

@Adrian
Maybe allow not only Addresses but Places to change to TX (and vv) too?

[AdrianBruce]

Joop - my instincts would be to allow changes from something else to text because I am assuming that is less restrictive and I can see people might want to go that way.

Vice versa is, I am guessing, from a fairly free format item to one (place or address) with more restrictions. That worries me because I don't understand enough about what use is made of the definition that something is a place / address etc. Could one create a source record with elements that could not be created otherwise? That sounds risky. On the other hand - how else could / should one alter things?

[JoopvB]

Adrian, yes changes to TX are not really a problem (must have something to do with the entropy of information ).

For the plugin vice versa is not a problem too (it's like entering the text in the place field in the property window). It's more about would we want that. I've been hesitant about allowing it because, as you already mentioned, both Places and Addresses have format conventions to adhere to.
This was the reason I only allowed NM --> TX and vv. I decided to keep the // for the last name in the TX field, but am more and more convinced that removing them is better.

[AdrianBruce]

"Entropy of information".... Phew! My impression is that is heavy theoretical physics!

Now I really don't know enough about these formats (still being on v6) but if it means what I think it does, turning a NM field into a TX field, really should lose the //. My logic is that the // only has meaning in the context of a name - if you turn what was a name into a plain simple text field, that context isn't there any more so I would have thought that the // must be removed, as you suggest.

If you were to go in the reverse direction (text to name), I really don't think that you can insert the // because you don't have any knowledge of whether the incoming text is supposed to be a name with a leading family name or a more usual (in our context) trailing family name. Or whether there's a prefix and / or suffix. Surely there have to be limits on what software can do in this sort of conversion?

[JoopvB]

Linked, the updated version of Change source template for testing: Change Source Template

Changes are:
- mapping from AD, PL and NM to TX allowed;
- when mapping from NM to TX the slashes (/) are removed;
- mapping from TX to NM is allowed with standard FH last name conventions (i.e. last part of multipart name is last name);
- mapping from AD to PL and vice versa is allowed;
- Help button in field selection window added but no plugin store text yet.

My tests looked good, please try it out.

@Adrian: about last name conventions. I'm Dutch and we use a lot of last name prepositions like 'van', 'de', 'van der' etc. For another plugin that parses Dutch archive websites I use a script that parses Dutch names to find (most of) the prepositions and places the slashes accordingly. I guess the success rate is above 90%.
Since prepositions are highly language dependent It would be great if CP would extend the interface of their Language pack solution to incorporate routines like this.

[evinther]

Hi JoopvB,

Really nice plugin. I don't suppose you could be tempted to make a verion 2 which also enables removal of any custom template, i.e. change to Generic Source template?

Erik

[tatewise]

There is no Generic Source template as such but simply a lack of any Source Template.
So simply delete the link to the Source Template in the Source record and it becomes a Generic Source.
Any unused Source Template record can be deleted in the Records Window.

[Mark1834]

But do not do that with a Templated Source that has citations (i.e. one that you have used in your project). Without the template to define the fields, the citation data disappears from view! It is still there, but hidden under the "All" tab.

[JoopvB]

Hi Erik,

To make sure I understand your question:
- you have custom templates that have been used for cited sources?
- you would like to retain as much of the entered data (and citation links) for each of these sources and have that copied to a generic source?

What, if I may ask, is the reason you would want to revert from a more structured level of data arrangement to a lower level?

Joop

[evinther]

Hi Joop,

When I asked the question, I was basically blank on the topic of source templates, and I was ‘learning by doing’ – actually continuously failing in achieving what I wanted. At one point I wanted to restore all the sources I have messed up back to the generic template and start over.

Since then, I have been reading up on the topic, and getting some help from Mike Tate, and I now have a much better understanding of templated sources. I now see that your question is right to the point, and it would be rather foolish to go from a structured template back to the generic one. Especially when I can use your excellent plugin to update my sources from one revision of a template to a newer one (there is still an element of trail-and-error in my case).

Now that I have come to love templated sources, I wonder if it would be possible to change an existing source from generic to templated?

An additional question: is there a complete list of all data referencing elements like %SOUR.REFN% that can be used I FH. I can pick bits and pieces in FH Help and in the forum, but I can’t find a complete reference description. Maybe I should look for this in the GEDCOM standard?

Regards
Erik

[JoopvB]

Hi Erik,

As to your first question: Yes it is possible to convert generic sources to templated. I did it for my generic sources. But... the plugin is very depended on your naming convention of the generic sources, your usage of the source note field etc. So, if you would want to explore that path, I'd be happy to send you my plugin but be prepared to rework it substantially to get it working on your data. With rework I mean use Lua to do your own coding. That's not as bad as it sounds. There are lots of people (including me) on this forum that are there to support you.

About your second question: the FH Help contains all the information I ever needed and is, as far as I know, complete.

Regards, Joop

[ColeValleyGirl]

The FH help is a good starting point, as are the Data Reference Assistants that are available e.g. when you're creating queries, but there are a few things the Data Reference Assistants don't help with and you have to work things out using firs principles, known examples and ocasonally resorting to the Gedcom standard to identify little-used tags.

[evinther]

Thanks both for your reply.

@Joop
Good to hear Sure, I would appreciate a copy of your plugin. I see some info on lua.org, but is there a deveopment environment available?

@ColeValleyGirl
Ahaaa ... the custom query builder actually shows the full monhy of available data, and how to reference them. Good tip! (I assume this is what you call the Data Reference Assistants?)

Regards
Erik

[ColeValleyGirl]

You can develop Lua within FH -- Tools > Plugins > More > New will bring up a blank editing window. If you prefer, there are external editing environments -- Zerobrane or Visual Code both work well, but you always have to debug within the FH environment.

[evinther]

Thanks Helen. FH i quite a versatile tool !!!

[JoopvB]

Hi Erik,

Attached is the plugin. The project dependent part of the script is separated from the part that is handling the code for reading, checking and writing of the template, source and repository records.

As Helen already answered, the built in tools of FH will be a good start to work with Lua. Open the plugin (edit), save it under another name and start experimenting. I suggest to always work with a copy of your project. Usually the effects of plugins can be reversed by FH, but better safe then sorry.

Good Luck, Joop

[evinther]

Thanks Joop