[sword-devel] load v11n from file

[Konstantin Maslyuk]

> I. Currently
>   1) We force module developers to choose a v11n.  This is painful for
> them, but in their own interest, as it will enable their module to work
> within the future utopia of a cross-module equivalent content
> reconciliation implementation (CMECRI, pronounced: see-me-cry)
>    2) The downside for the module developer is:
>     a) their module sometimes has verses concatenated together if they
> choose a v11n which doesn't have enough 'slots';
>     b) worse, they don't have a v11n yet available to choose

I would agree here, for the sake of few places that can be forced to any
existent v11n there is no need to define and use module-supplied v11n.

Except definition of 'future utopia', at least because i have everything
to define and get the same content for such unlike modules as KJV and
RusSynodal.

> II. If we enable the ability for a module to supply something like
> <DataPath>/v11n.conf, which defines a custom v11n, I fear:

I hope that i persuaded you that path #2 is preferred, because in relation
of user repositories with path #1 collisions are inevitable.

>   1) PEOPLE WILL ACTUALLY USE IT... always... because they are
> shortsightedly of the opinion it is 'right'.
>     a) Module developers will never accept I.2.a, but instead will
> always define their own v11n so their verses will never be merged with
> another verse.
>     b) I can see module repositories existing which publish Bibles and
> Commentaries which always include a v11n.conf.  We cannot optimize for
> this and cannot easily move forward with CMECRI in this hypothetical
> scenario.

I m not sure, define v11n with mappings is not a simple thing. If you make
changes in canon you also need to define how this changes are mapped. It is
additional work that need a lot of attention to make every thing work
right. I'm
not sure that for module maker way to contract or expand a few of verses is
simpler then to define own v11n. Even in regard of that module maker thinks
that his source is the most right.

I can share concerns of that tomorrow every module maker will make own
v11n. But i also was witnessed that engine changes would destroy a module,
when
in Synodal canon in Psalms was added one verse, and i got skipped first
verse
in every chapter across the rest of OT.

It is great if module maker forced to use any standard v11n for his
module, but
it will be terrible if one day in that v11n something will change. If we
change
something in canon in engine then, we need to synchronously update all
existing
modules of that canon.

With external v11n displayed result will always be the same.

Summarize, we may need external v11n to avoid desynchronization of v11n in
engine
and module, but we may need to close access to the tools.

>   2) WE LOSE MOTIVATION
>     a) for module developers to do the hard work and give us the
> information we need about their module, for us to move forward with
> CMECRI. e.g., we need to know with which v11n their module best fits,
> and we need to know where the exceptions lie.  I realize we can still
> ALLOW them to provide this data, but if they are not forced to make
> these decisions, like they are currently forced to do, they will not
> make these decisions.
>     b) for us to continue to define v11n systems.  If we don't need to
> define a common denominator v11n for a set of modules before we can
> release them, we won't... well, we won't as quickly as we would if we
> had to.

Agree, centralized work over v11ns is still necessary.

You have very strict policy of accepting modules even not regarding to
copyright issues. I have Russian Commentary that was ignored twice on
modles �� crosswire.org (i cant remember, at least ones).

Open Source gives ability to do every thing to anyone with preservation
of centralized development.

> _______________________________
>   Just to be sure we both have the save vision of module v11n utopia, I
> think we both have similar desires like:
>  All the world's v11n systems defined internally in the engine in under
> 50 v11ns.
>  CMECRI between any 2 systems.
>  Module developers have to choose the best match, and provide exceptions,
> (which even allows verses to exist which otherwise might be merged, and
> which CMECRI takes into account).
>   Yes?

I do not see difference internally or externally if we talk about final.
Internally it is normal for me and i can agree with this.

But this thread is more about how we will achieve this 50 v11n with correct
transitions between.

And would i consider this as lets delay publication of Russian modules for
years yet, to ensure we have correct mappings to other v11ns?