@rileydog I'd like to start over with a very simple approach given the following base scenario:
I want/ my customers needs:
- a standardized format, to be exported and imported if needed
- multilingual vocabularies
- TTW editing of simple and tree vocabularies in Plone.
So let sketch me the base idea. But some code history first:
ATVM was written for Plone 2.1 and got extended with the help of lots of people. Today I'd no longer use content types to build up a list or tree to describe vocabularies. I also would not use the content translations to build up multilingual vocabularies.
How to implement it:
First we cover (1) and (2) above already with
collective.vdexvocabulary. VDEX is in fact a very simple well defined XML format - simple if we skip the feature of references. Latter is rarely used and may be implemented later.
But c.vdexvocabulary does solve it on zcml level not on content level. Neither has it an editor. In c.vdexvocabulary vocabularies are registered with zcml. If we turn them into plone.resource based resources they can exist in FS and in ZODB. We change the registration part from zcml to registry.xml. Currently the ZCML directive registers a
zope.schema.interfaces.IVocabularyFactory utility. We may turn this in a local component (which I personally dont like much, I'd investigatre here to find a better solution). We reuse the VdexTranslationDomain to handle translations.
Since then its easy to edit the xml ttw. With a control panel -also to create new vocabularies and a text field - maybe using ACE editor - its still editing XML and thats not that comfortable, but would work at first.
In a second step I'd write a JS editor for VDEX. This can be a simple one showing a tree at the left and a form for the entry at the right or something more complex, but since vdex is a tree of simple nodes key ->en: value, de:value, ... this is not that difficult, but needs some UI planning.
I'd not continue on c.vdexvocabulary but create a new package. c.vdexvocabulary is used in the wild and the code in it is not very consistent. Given one want to migrate from c.vdexvocabulary to the new package its easy because its just a vdex file to move around and some zcml to registry changes.
Reusing the treevocabulary code together with it's translation mechanism saves time and testing. It uses the imsvdex python package which is a bit aged but just works, at first I'd keep it as is.
Then we need the new registration and control panel.
Upon here we have a fully working addon. I'd say until I'd estimate roughly at 4-5 days plus 1 day fixing Plone bugs to be found while working on it.
The JS Editor for VDEX is now the next thing. This is difficult to estimate without a better concept. Very very roughly I estimate 1-2 days for UI/UX planning and 3-4 days for implementation.
Migration from ATVM:
Given one has important vocabularies in ATVM, even multilingual, the writing an exported to vdex is not complex. Given writing an exporter to CSV is even easier, vdexcsv may be used to convert.