On 5/28/19 9:24 AM, Cyrille wrote: > > > Il 28/05/2019 17:40, Troy A. Griffitts ha scritto: >> >> So, a little background surrounding why the logic is difficult to >> work out a solution for this problem: >> >> The current verse parser, which works fairly well, always has 3 sets >> of possibilities in view: >> >> OSISRef >> Current Locale >> English >> >> The parser needs to handle any of these three, typically in the >> preference order listed above. The issue with changing out symbols >> while parsing is that some symbols (notoriously the comma) are used >> for different purposes across these 3 sets. >> >> One might think that localized output might be easier than parsing, >> e.g., once parsed, we could at least output the reference: Jn 3,16. >> The problem here is that what the engine outputs it also expects to >> be able to parse. >> >> While we would like to solve this problem, it isn't as simple as >> adding to the locale files: >> >> ChapterVerseSeparator=, >> >> RangeSeparator=- >> >> ListSeparator=. >> >> This would be enough to define the locale, but not solve the >> problem. We would need a fundamental change in how parsing is done, >> e.g., explicitly telling the parser, "Hey, I'm sending you localized >> input, so don't guess. You can count on the symbols I'm sending you >> to be localized" Right now everyone has the convenience of just >> passing any of the 3 sets of parsing text listed above and theparser >> just figuring it out-- with the caveat that chapter, range, and list >> separators are not localizable. >> >> Hope this gives some background, >> > Yes thank you, but I just don't understand why it is already possible > with two separator (. and : ) and then not only with one? Maybe I > can't understand it because it is too much hard (technicaly) for me ;)
Because ':' is unambiguous between all three. '.' retains OSIS semantics and is book and chapter separator between all three. The problem comes when you have an entry like: Jn 3,16 Currently, the parser will understand this as John chapter 3 and chapter 16. You obviously would want this to be chapter 3, verse 16. The question is, when does the parser decide it is a list separator and when does it decide it is a chapter/verse separator. It is ambiguous unless you tell the parser: "This is strictly locale formatted text. It is not OSIS. It is not English." Hope this helps clarify. Troy >> Troy >> >> >> On 5/28/19 6:10 AM, David Haslam wrote: >>> OK - but my observations were not entirely irrelevant. >>> >>> Some front-ends never need the user to enter a reference in an edit >>> box. Navigation is done entirely via menu selections or clicking >>> search results etc. >>> AFAICT this is true of PocketSword. >>> >>> Other front-ends are designed at the opposite extreme. All >>> navigation is done through an edit box. This is true (eg) of STEP >>> Bible. >>> >>> Best regards, >>> >>> David. >>> >>> Sent from ProtonMail Mobile >>> >>> >>> On Tue, May 28, 2019 at 13:54, ref...@gmx.net <ref...@gmx.net >>> <mailto:ref...@gmx.net>> wrote: >>>> Sorry, David, that is a complete misunderstanding. Modules need >>>> osisref. There is and will be no need to do anything to the >>>> modules. This is about the engine parser to read references locale >>>> appropriately. >>>> >>>> Sent from my mobile. Please forgive shortness, typos and weird >>>> autocorrects. >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [sword-devel] C++ volunteer >>>> From: David Haslam >>>> To: SWORD Developers' Collaboration Forum >>>> CC: >>>> >>>> >>>> Parsing native references is not a simple task, as we know from >>>> the fact that adyeths orefs.py was kicked into touch indefinitely. >>>> >>>> And that’s even when punctuation marks are defined in the >>>> specified configuration file. >>>> >>>> Unless we might consider the possibility of adding keys to >>>> module .conf files that define the module specific >>>> native reference punctuation marks and separators. >>>> >>>> That could be a huge undertaking, considering the need to >>>> maintain backwards compatibility. >>>> >>>> And it’s not as if it really is module specific entirely. A >>>> user can be switching between modules with different languages, >>>> yet would need the current reference to always work, no matter >>>> what. >>>> >>>> Best regards >>>> >>>> David >>>> >>>> Sent from ProtonMail Mobile >>>> >>>> >>>> On Tue, May 28, 2019 at 12:10, ref...@gmx.net <ref...@gmx.net >>>> <mailto:ref...@gmx.net>> wrote: >>>>> The improvement request for allowing commas in references... >>>>> adding commas in the suggested form would make millions of >>>>> currently valid Anglo references invalid. The problem is a >>>>> much wider one, references should be localised in their >>>>> punctuation too. I am not sure how difficult this would be, >>>>> but I guess we could make a start by defining what punctuation >>>>> is used for which purpose , and then take it from there. >>>>> >>>>> Cyrille, maybe start a page on the wiki and start thinking there. >>>>> >>>>> Sent from my mobile. Please forgive shortness, typos and weird >>>>> autocorrects. >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: [sword-devel] C++ volunteer >>>>> From: Cyrille >>>>> To: SWORD Developers' Collaboration Forum >>>>> CC: >>>>> >>>>> >>>>> Hello Richard, >>>>> Welcome! >>>>> May I make a very selfish proposal to Richard who offers >>>>> his help. There are two issues that I really want to be >>>>> resolved. One of which particularly handicaps Catholic >>>>> users, (but I discovered today that the issue wasn't been >>>>> reported!!! I just did it): >>>>> https://tracker.crosswire.org/browse/API-216 >>>>> And the second: >>>>> https://tracker.crosswire.org/projects/API/issues/API-180 >>>>> >>>>> If there are more important things that I am not able to >>>>> estimate not being a developer, I would have tried my luck ;) >>>>> >>>>> Il 28/05/2019 01:38, Troy A. Griffitts ha scritto: >>>>>> Richard, sorry, I meant to give you the link to our tracker: >>>>>> >>>>>> https://tracker.crosswire.org >>>>>> >>>>>> >>>>>> On 5/27/19 4:32 PM, Troy A. Griffitts wrote: >>>>>>> Welcome, Richard! >>>>>>> >>>>>>> I would start at 2 places: >>>>>>> >>>>>>> First, have a look at our tracker here. We are not very (very >>>>>>> not) >>>>>>> disciplined at keeping it current. Skimming through there and >>>>>>> commenting on anything that looks interesting, or even cleaning >>>>>>> a few >>>>>>> things up in there that you confirm are no longer a problem >>>>>>> might be a >>>>>>> useful exercise to get you poking around at internals and would >>>>>>> be a >>>>>>> blessing for us. Our modus operandi as of late is to create a >>>>>>> new unit >>>>>>> test in sword/tests/testssuite/ which fails at the bug and then >>>>>>> once >>>>>>> fixed, the test should pass and we leave the test around to be >>>>>>> sure we >>>>>>> don't regress. We can always use more tests in our tests suite. >>>>>>> >>>>>>> Next, we have the intention to modularize our search engines >>>>>>> support and >>>>>>> search types. Right now, SWModule (which represents a Bible) >>>>>>> implements >>>>>>> our SWSearchable interface, which is fine, but right now it has >>>>>>> a bunch >>>>>>> of #ifdef logic and switch statements to take different code >>>>>>> paths >>>>>>> depending on which search engine is compiled into SWORD and >>>>>>> which search >>>>>>> type is specified. This was fine initially, but has grown to >>>>>>> such that >>>>>>> we now support spaghetti in there. It should probably simply >>>>>>> have a set >>>>>>> of SWSearchable objects in a map<SEARCH_TYPE, SWSearchable> and >>>>>>> proxy >>>>>>> the search request to the appropriate SWSearchable impl based >>>>>>> on what >>>>>>> types are registered for the module. This would allow us to >>>>>>> implement >>>>>>> new types and register them with modules which support special >>>>>>> search >>>>>>> types, e.g., advanced Hebrew Morphology searching. That's the >>>>>>> general >>>>>>> idea anyway. >>>>>>> >>>>>>> You should probably become familiar with SWFilter and how we >>>>>>> use these >>>>>>> throughout the engine. These prepare a buffer for particular >>>>>>> objectives. We have RenderFilters, EncodingFilters, >>>>>>> StripFilters, ... >>>>>>> The last prepares an SWModule entry for searching by, typically, >>>>>>> stripping out all markup and leaving only a plaintext buffer >>>>>>> which can >>>>>>> be searched. We have some special code in the SWModule::search >>>>>>> spaghetti which takes Greek and Hebrew modules and turns >>>>>>> buffers into a >>>>>>> series of Strongs#@MorphCode Strong#@MorphCode ... which allows >>>>>>> regex >>>>>>> searches to do some advanced morph searching... like: Find this >>>>>>> strongs >>>>>>> number, any morphology, followed by a any verb withing 2 words. >>>>>>> You >>>>>>> have to be pretty familiar with the Strong#@MorphCode syntax to >>>>>>> formulate something like that, but the idea is that a frontend >>>>>>> could >>>>>>> have a nice UI to help a user come up with some creative >>>>>>> searches. >>>>>>> Anyway, these should all be probably modulized out by renaming >>>>>>> the >>>>>>> StripFilter concept to SearchFilter, and then pushing all this >>>>>>> special >>>>>>> code out to SearchFilter impls which do these special things... >>>>>>> >>>>>>> Finally, an objective of all this search modularization is also >>>>>>> to break >>>>>>> out the code required to create search indexes for each of the >>>>>>> search >>>>>>> engines we support. Ideally, we should be able to support the >>>>>>> same >>>>>>> searches either as an indexed or brute force search. The same >>>>>>> code >>>>>>> which iterates a module, prepares each entry, and pushes that >>>>>>> entry to >>>>>>> the search engine, building the search index, should also work >>>>>>> for a >>>>>>> brute force search-- iterating the module, preparing each entry >>>>>>> for the >>>>>>> search engine.. and then performing a check on that buffer to >>>>>>> see if it >>>>>>> matches the search expression. >>>>>>> >>>>>>> I hope this gives you a few things to think about. It has been >>>>>>> good for >>>>>>> me to refresh thoughts on all of this. Have a look and let me >>>>>>> know what >>>>>>> you think. >>>>>>> >>>>>>> Welcome! Looking forward to sharing in service together, >>>>>>> >>>>>>> Troy >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/27/19 1:09 PM, Richard Smith wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> My name's Richard Smith. I'm a C++ software engineer with 10 >>>>>>>> years >>>>>>>> experience in various industries. I was wondering if there was >>>>>>>> any >>>>>>>> space for a volunteer. I've started taking a look at things >>>>>>>> (building >>>>>>>> repos on Win/unix), but if there are specific things that are >>>>>>>> required, within my ability, I'm happy to do that. >>>>>>>> >>>>>>>> Best Regards >>>>>>>> Richard Smith >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel >>>>>>>> Instructions to unsubscribe/change your settings at above page >>>>>>> _______________________________________________ >>>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel >>>>>>> Instructions to unsubscribe/change your settings at above page >>>>>> _______________________________________________ >>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel >>>>>> Instructions to unsubscribe/change your settings at above page >>>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> sword-devel mailing list: sword-devel@crosswire.org >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >> >> _______________________________________________ >> sword-devel mailing list: sword-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page > > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
