<p dir="ltr">3) Use the same model as operating systems do for opening urls or file types that have multiple registered handlers. Let the user select which to use and possibly set a default.</p>
<div class="gmail_quote">On Aug 31, 2015 8:49 PM, "Peter von Kaehne" <<a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My take on this is following:<br>
<br>
To have a rule of no clash for abbreviations with ModuleName is unreasonable. The whole point of Abbreviation is that i can name my modules how they are named in common parlance. Irrespective of if there is somewhere else, in a language i do not care about a module which uses module's Abbreviation as ModuleName.<br>
<br>
At the same time, soneone who has two modules installed where a clash is a problem needs a way out.<br>
<br>
Two options:<br>
<br>
1) let the user fix it if there is a clash, assist the user finding clashes, e.g. during install.<br>
<br>
2) do not allow Abbreviation in the url.<br>
<br>
Peter<br>
<br>
<br>
<br>
Sent from my phone. Apologies for brevity and typos.On 31 Aug 2015 23:59, Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>> wrote:<br>
><br>
> The particular example at hand is KJV vs. engKJV2006. I know that Michael is removing the latter from eBible repo, but this is a specific instance of a general problem. So I will use it as my example.<br>
><br>
> Problem: KJV is a real module name. engKJV2006.conf contains Abbreviation=KJV.<br>
><br>
> David Haslam noticed a glitch in my new Xiphos 4.0.4: If one is currently displaying KJV, and uses the context menu by which to change one of the module settings (e.g. en/disable Strong's or morph), then engKJV2006 is substituted in display. The option change requested is recorded for KJV, but engKJV2006 is displayed according to its previously-defined options.<br>
><br>
> The sequence by which Xiphos trips over this is:<br>
> - Xiphos uses the real non-abbrev name KJV by which to change the option requested. Fine so far.<br>
> - Xiphos then constructs an internal URL by which to induce re-render of the chapter under the new option setting, e.g. sword://KJV/Gen.1.1. In principle, this is again fine so far.<br>
> - This URL is handed to a different part of Xiphos which expects to evaluate module abbreviations. Here, it finds that KJV is an abbreviation for engKJV2006, so it substitutes the latter even though KJV was being displayed and had just had its options changed.<br>
><br>
> The error is one-way: If KJV is displayed, and an option is changed, engKJV2006 will be substituted. But if engKJV2006 is displayed, and an option is changed, engKJV2006 will still be displayed. This gives an odd "higher value" on the aliased name rather than the real one.<br>
><br>
> As I've thought about this, my conclusion is that the fundamental problem is not that Xiphos wants to re-interpret potential abbreviations so as to find real module names; rather, the problem is that there is in effect a pretender to the name. Abbreviation=XYZ must never name a real module already named XYZ. This is an inherent semantic conflict that I think is not reasonably resolvable. For example, some frontends including Xiphos can be started using such a URL as a command line argument. How is the user to get the real module, if the abbreviated pretender is always to be preferred?<br>
><br>
> I believe I would like to see us make a policy requirement statement to this effect, i.e. that Abbreviation=XYZ must not name an existing real module XYZ.<br>
><br>
> Aside: Michael suggested that the Abbreviation config directive is language-specific, i.e. if thaKJV2003.conf contained Abbreviation=KJV, this would be an alias specific to the ภาษาไทย (Thai) group of modules and would not "cross over" to English modules. I cannot find any support for this specificity anywhere in the wiki. Could someone more knowledgeable clarify?<br>
><br>
> --karl<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page</blockquote></div>