[sword-devel] Open Hebrew Lexicon. (David Troidl), (Daniel Owens)

[David Troidl]

Hi,

The main problem with wiki markup, from my point of view, is that it 
requires editing behind the scenes, and has no real error checking.  For 
quite a while I had been editing my lexicon in a good text editor, but 
more recently invested the time in making a PHP interface that abstracts 
away most of the niggling technical headaches.

Peace,

David

On 9/5/2011 5:37 AM, Benjamin Misja wrote:
> Hi,
>
> This might be a silly idea from a non-techie, but why not just use a Wiki?
> Markup is simple, far more people will be familiar with it, it's platform-
> independent and doesn't require any additional software to be installed. In
> addition, your work would take place in a more public setting, thus motivating
> more people to use it and join in, even with small fixes, and giving it more
> notoriety.
>
> I'm following this thread with interest.
>
> God bless,
> Ben
>
> Am Sonntag, 4. September 2011, 21:48:44 schrieb Daniel Owens:
>> Snip...
>>
>> On 09/04/2011 01:12 PM, David Troidl wrote:
>>> Hi Aaron,
>>>
>>> On 9/4/2011 10:50 AM, Aaron Christianson wrote:
>>>> Daniel,
>>>> This does sound very much like what I am interested in doing, but
>>>> unfortunately, you seem to be using WeSay, which appears to have some
>>>> deficiencies in it's Linux versions that will make it unusable for
>>>> editing a work of this kind (no support for non-latin scripts, and
>>>> issues copying and pasting non-ascii characters).  I'm afraid that I
>>>> use Linux exclusively, and my ability to contribute to this project
>>>> would be severely limited.
>> Yes, for a Linux-only or a Mac person, this is a significant problem. I
>> am a mainly-Linux person, and I am waiting eagerly for WeSay to be fully
>> functional in Linux (without holding my breath). The reason I chose
>> WeSay was to encourage non-techies with an easy-to-use application that
>> supports structured collaboration using a version control system. It
>> works great with unicode in Windows, handles multiple contributors
>> easily, and is developed by people trained and experienced in creating
>> lexica. One additional useful feature is that it offers the ability to
>> add semantic domain information. However, for our purposes WeSay is
>> basically limited to Windows at this point.
>>
>>> I was going to write to Daniel privately, but maybe this is a topic
>>> that needs to be brought up here.  My concern is the proliferation of
>>> formats, trying to accomplish the same thing.  With Daniel's LIFT
>>> dictionary, the SWORD TEI-based lexicon format, whatever you would use
>>> and my ad hoc schema, all with similar goals, there could be a lot of
>>> duplication of effort.
>> Yes, I also don't like the idea of duplicating efforts.
>>
>>> I made my schema just to get into the work, and with the intention of
>>> making it easy to transform to another format, when there was
>>> something better.  I know that the TEI could handle all the
>>> requirements, but it's huge and forbidding.  The SWORD format examples
>>> I've seen appear dense and hard to understand.  I'm not certain if it
>>> has all the capabilities my lexicon needs.  I was going to ask Daniel
>>> if his LIFT dictionary could handle it all, and what would be required
>>> to transform between the two.  Also if his setup could import
>>> transformed entries.  Now if WeSay is a problem with Linux, is that
>>> insurmountable?  Could the LIFT dictionary be used in another
>>> context?  Or what other format would be better?
>> On formats: SWORD's implementation of TEI for a lexicon is probably not
>> the best format. At least I have not considered it to be a good format
>> for creating a lexicon. I chose LIFT XML because it is a format that
>> several SIL programs use (WeSay and FieldWorks). It is designed for
>> lexica, so I imagine it can handle anything we need. WeSay allows you to
>> create custom fields, which makes it easy to work with. LIFT is just an
>> XML standard, so there is nothing to prevent one from creating an
>> application to write to a LIFT XML file.
>>
>> On applications: I have been ruminating on the problem of WeSay being
>> Windows-only and wondering if a browser-based solution written in PHP or
>> something like that would be a "quick" solution for Mac and Linux users.
>> The PHP code and LIFT file could reside on the contributor's machine
>> with Mercurial negotiating the differences with the server. That would
>> mean the PHP program would have to be written to work well with WeSay,
>> which could be a job in itself. I just don't have the time or expertise
>> to pull it off. But if someone could do that, it would open up
>> possibilities for contributors.
>>
>> Our project is moving so slowly that I am open to changing the way we do
>> it. Data format questions aside, the following features are needed for
>> an interface for developing a Hebrew lexicon:
>>
>>      * Support RtoL Unicode
>>      * Easy to use for non-techies (virtually brainless, if possible)
>>      * Changes stored using a version control system allowing for
>>        collaboration
>>      * Support features that are commonly accepted as good linguistic
>>        practice, such as semantic domains
>>      * Customizable for our needs
>>
>> So far WeSay works the best for that, but it is limited to Windows. I am
>> open to new ideas.
>>
>> Daniel
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page