Bulk edit
Bruce Hooley
Ronald Moe
• Use Bulk Edit Senses—Bulk Replace.
• In the “Find what” box put:
$
• In the “Replace with” box put:
. [that’s a ‘period’, if you can’t see it]
• Check “Use regular expressions”.
Then use Bulk Replace to find two periods and replace them with a single period.
You might want to first filter for two or three periods in case you are using them for any special purpose…
But adding an extra period and then deleting it shouldn’t make any difference.
Ron Moe
No virus found in this incoming message.
Checked by AVG.
Version: 8.0.134 / Virus Database: 270.4.3/1529 - Release Date: 7/1/2008 7:23 PM
Beth B
..+[^.]$
That will find everything that ends with something that is not a dot.
Then as long as those are the only ones showing, you can use the Bulk
Replace tab to do this (make sure "use regular expressions" is ticked):
Find: ^(.+)$ Anything, starting from the beginning of
the string, going to the end, and remembering it as a group.
Replace: $1. Put in what was in the first (only) group, and then
put a dot after it
-Beth
Beth Bryson
> You want your filter to be:
>
> ..+[^.]$
>
The first dot isn't necessary--not sure why I put it there. The .+ ensures that there is at least one character in your definition besides the thing that isn't a period. I guess strictly that isn't necessary either. This:
[^.]$
would match any string where the final character is something other than a dot. (It would match strings of one or more characters.)
-Beth
Ronald Moe
Do you know how to filter out all punctuation? I don't think we want to add
a period to a definition that already ends in a punctuation mark:
This is a definition for a word that means Hey!
>
This is a definition for a word that means Hey!.
So we either need to first filter out all definitions that end in a
punctuation or quote, or we need a more sophisticated "Find what" that finds
a string that doesn't end in a punctuation or quote.
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of Beth Bryson
Sent: Wednesday, July 02, 2008 9:30 PM
To: flex...@googlegroups.com
[^.]$
-Beth
No virus found in this incoming message.
Beth B
> Do you know how to filter out all punctuation? I don't think we
> want to add
> a period to a definition that already ends in a punctuation mark:
Okay, yes, you're right. So we need to add to the set of things that
cannot be
the final character, and the filter should have been:
[^.!?]$
If you want to include " in it, you might have to escape that with a
backslash. Or just use a different pass to look for things that end
with " and see if there is punctuation before that.
You can of course add whatever you want to that set--do you want
comma in there? semicolon? You could first sort your definitions
from the end, and then look at the beginning and end of the list, to
see what things your definitions *do* end with..... Or run the above
filter and *then* sort from the end, to see if there is any *other*
punctuation that your definitions end with, that you should account for.
-Beth
Bruce Hooley
Thanks very much for your and Ron's help. It worked beautifully--for the
definitions. But the examples was another story!
Here's what I did: From Lexicon Edit, I filtered for .+[^.!?]$. , but it
didn't remove the examples with a fullstop/period already there--at least
not all of them. And there were at least a couple which had ? still there.
So I'm not actually sure what it did remove. There were 4116 entries to
start with and it filtered down to 3689. So I thought I would just add a
final fullstop to them all, and then go and look for occurrences of .. !.
and ?. I moved over to Bulk Edit Senses to try and do a Replace, and it said
there were 4770 entries. I assumed that meant I had more than one example
for a number of entries. But the only option it offered for the Target Field
was Gloss [I had Headword, Lexeme Form, Glosses, Entry Type and Examples
open in the Entries Pane of Lexicon Edit, and Headword, Grammatical
Category, Gloss and Examples in Bulk Edit Senses], so I didn't know how to
proceed.
Just to check it out I decided to run the filter from the Bulk Edit Senses
page. There it said there were 4770 entries to start with, and when I ran
the filter it said there were 4303, but again there were examples which did
have . and ? already there. But it still only offered Gloss as an option for
the Target Field.
So it looks like I can't actually use bulk edit to do what I want--or have I
missed something?
----- Original Message -----
From: "Beth B" <lxb...@yahoo.com>
To: <flex...@googlegroups.com>
Sent: Thursday, July 03, 2008 1:09 PM
Subject: [FLEx] Re: Bulk edit
>
max...@umiacs.umd.edu
> From Lexicon Edit, I filtered for .+[^.!?]$. , but it
> didn't remove the examples with a fullstop/period already there
> --at least not all of them.
Any chance you had space characters after the final full stop?
Mike Maxwell
CASL/ U MD
John_T...@sil.org
> Thanks very much for your and Ron's help. It worked beautifully--for the
> definitions. But the examples was another story!
>
> Here's what I did: From Lexicon Edit, I filtered for .+[^.!?]$. , but it
> didn't remove the examples with a fullstop/period already there--at least
> not all of them. And there were at least a couple which had ? still
there.
> So I'm not actually sure what it did remove. There were 4116 entries to
> start with and it filtered down to 3689. So I thought I would just add a
> final fullstop to them all, and then go and look for occurrences of .. !.
> and ?. I moved over to Bulk Edit Senses to try and do a Replace, and it
said
> there were 4770 entries. I assumed that meant I had more than one example
> for a number of entries. But the only option it offered for the Target
Field
> was Gloss [I had Headword, Lexeme Form, Glosses, Entry Type and Examples
> open in the Entries Pane of Lexicon Edit, and Headword, Grammatical
> Category, Gloss and Examples in Bulk Edit Senses], so I didn't know how
to
> proceed.
MikeM had one good suggestion...could there be spaces at the end of your
pattern? Or, at the end of your data? You may wish first to filter for " +
$" (space-plus sign-dollar) which will find things with at least one space
at the end, and clean that up.
The other issue is that 'Examples' is a sequence property. You can have
more than one example sentence per sense. This raises the question, if
there is more than one example, what exactly does it mean to say that there
is no period at the end? Should it mean that all the examples have no
period? At least one has no period? Or what?
What we have actually done is probably not ideal from any point of view
except being straightforward to program and making it easy to understand
what is going on: we find things that have no period at the end of the
total contents of the cell in the browse view. What this amounts to is
finding senses where the LAST example has no period. That's probably of
marginal usefulness if you actually use multiple examples, but it's what we
have for now.
>
> Just to check it out I decided to run the filter from the Bulk Edit
Senses
> page. There it said there were 4770 entries to start with, and when I ran
> the filter it said there were 4303, but again there were examples which
did
> have . and ? already there. But it still only offered Gloss as an option
for
> the Target Field.
>
> So it looks like I can't actually use bulk edit to do what I want--or
have I
> missed something?
No, you haven't missed something. Not all fields you can display in bulk
edit can actually be bulk edited. In the configuration dialog you will see
a blue-circle-with-two-arrows icon next to the ones that can be bulk
edited. Even of those, only some can be bulk-edited with text-replacement
functions; otherse can only be manipulated using List Choice functions.
There are various reasons why certain fields can't be bulk edited, mostly
having to do with possible confusion about what bulk editing would mean. In
the case of Examples, again, we are up against the problem that there can
be multiple examples. If there are, we are faced with deciding what a
change means. The Examples cell in the browse view can show multiple
examples, one per line. If we do a replace "at the end", should that be at
the end of each example, or the end of the whole cell? If we bulk copy some
other field into Examples (probably unlikely, but we have to consider the
possibility), would we replace the contents of both examples with the new
string? Set the first one to that and the others to empty? Or what?
It is possible to configure a column which displays the FIRST example. This
can be bulk edited unambiguously, and that may be sufficient for your needs
if you are not using multiple examples (or of some help even if you are).
To use it, you need to edit one of the FLEx configuration files: C:Program
Files\SIL\FieldWorks\Language Explorer\Configuration\Lexicon\RDE
\toolConfiguration.xml. (If you have not installed FLEx at the usual place,
modify as necessary.) Make a backup of the file! Find the section that
starts <tool label="Bulk Edit Senses"... Within that there are many column
elements; you can insert this one between any two of them:
<column label="FirstExample" visibility="dialog" multipara="true"
ws="$ws=vernacular"
width="90000" transduce="LexSense.Examples.Example"
cansortbylength="true">
<div>
<seq field="Examples" layout="empty" firstOnly="true">
<para>
<string field="Example" ws="$ws=vernacular"/>
</para>
</seq>
</div>>
</column>>
After that, you will need to restart FLEx while holding the shift key down,
to force it to load the new column definitions. You should then see
'FirstExample' in the bulk edit senses configuration dialog, and should be
able to do bulk edit operations on it.
Now, the translations of the examples are a sequence within a sequence. Let
me know if you need to bulk edit those...I'm not sure it is possible to do
even the first one without an enhancement to the program itself.
A better solution would probably be a bulk edit view focused on example
sentences (one row per example). The trouble is, following that pattern
could produce an overwhelming number of bulk edit views, and it would take
a lot of understanding of the model to navigate it. (For example, I suspect
many people are not even aware that they can have more than one example.)
To do it really thoroughly would need yet another for bulk edit example
translations, with one row per translation. Hopefully we can eventually
work out a good design that will handle this sort of thing intelligibly.
John Thomson
Ronald Moe
"A better solution would probably be a bulk edit view focused on example
sentences (one row per example). The trouble is, following that pattern
could produce an overwhelming number of bulk edit views, and it would take a
lot of understanding of the model to navigate it. (For example, I suspect
many people are not even aware that they can have more than one example.) To
do it really thoroughly would need yet another for bulk edit example
translations, with one row per translation. Hopefully we can eventually work
out a good design that will handle this sort of thing intelligibly."
In spite of the programming difficulties, this really needs to be done. It
is one of the most serious omissions in FLEx right now. We need to be able
to Bulk Edit every field. For instance I have discovered font problems in my
Greek dictionary that were created when I imported my file from Toolbox.
These problems are all through my example sentences. Without a way to use
Bulk Edit on the example sentences, I have to correct the errors manually. I
have a number of such jobs to do on other fields that I cannot Bulk Edit.
I'm brainstorming. Here is a suggestion for what the solution might look
like. Maybe we could create a single tool "Bulk Edit a field" to replace the
current bulk edit tools. The tool would first ask the user which field he
wants to edit. It would then "organize" the columns and available tools
according to what the field requires. If the user specified a sense level
field such as the Gloss field, he would be presented with the equivalent of
the current "Bulk Edit Senses" view (with appropriate restrictions on what
he could do with the target field). If the user specified that he wanted to
edit the example sentence field, he would be presented with a "Bulk Edit
Examples" view. In this way he could edit any field on any level of the
field hierarchy. He could display any other field along with the target
field and filter/sort the other fields. But he could only change the target
field, thus avoiding (some/all of?) the problems John raised.
I would think that we could design a tool (and Help files) that would enable
us to do what we need. I think such a tool would actually be more intuitive
than what we have now or (as John said) "an overwhelming number of bulk edit
views."
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of John_T...@sil.org
Sent: Monday, July 07, 2008 10:29 AM
To: flex...@googlegroups.com
Subject: [FLEx] Re: Bulk edit
John Thomson
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.4.6/1538 - Release Date: 7/7/2008
7:40 AM
John_T...@sil.org
How big a loss would it be, not to be able to configure the columns
separately for bulk edit entries and senses (and eventually other
varieties)?
Suppose, for example, that we made the combo that selects a field show all
the fields that can be bulk edited in any way, in any of the (underlying,
invisible) multiple BE tools. Then if you choose a field that requires the
Examples BE view, the program automatically selects that view, configures
it as far as possible to have the same columns with the same widths and the
same sorting and filtering, and if necessary switches you to the List
Choice tab (or to a non-list-choice tab, if it's not a list item...would
Replace be a good default?), and you're all set to bulk edit the field you
wanted.
Another variation would be to allow each BE view to have its own
configuration of columns, sorting, and so forth, except that if the current
configuration does not include the column you want to work on, it is
automatically added.
Note that in some cases, switching views would still make a visible
difference. For example, switching to the Examples BE view will hide any
rows that don't have examples, and split rows with multiple examples into
multiple rows. Sigh...I bet you want to be able to do things with all the
senses that don't have examples, so we probably need a way to make those
senses show up as if they had a blank example. (In fact the user probably
doesn't even want to know that there's a difference between having an
Example with a blank Form, and no example at all. We already hide the
difference in the main data entry view.)
JohnT
Bob & Barb Eaton
> Greek dictionary that were created when I imported my file from Toolbox.
> These problems are all through my example sentences. Without a way to use
> Bulk Edit on the example sentences, I have to correct the errors manually.
> I have a number of such jobs to do on other fields that I cannot Bulk
> Edit.
Not that a way shouldn't be added to do this in Flex itself, but if you're
doing a global kind of fix like this, another possible way to eat this
elephant would be thru SILConverters' XML Data Converter.
If you create an XML file of your database (thru backup) you could use an
EncConverter (e.g. CC table, ICU regular expression, SpellFixer, etc) to
"convert" the data in elements or attributes of the XML file based on its
XPath specification.
e.g. I just pulled all of the example sentences in my database out with:
//LexExampleSentence//Run
If you click the "?" in the upper right and click on the various parts of
the window, it'll gives some context sensitive help on how to use it.
Bob
P.S. if you're using FW 5.2, you'll have to copy the file FwExport.dtd from
\program files\sil\fieldworks\exportoptions to wherever the xml file is
located (and rename it to FwDatabase.dtd, which seems to be a mistaken
reference to it in the XML file). Otherwise, the XML Data Converter will
complain about not being able to find FwDatabase.dtd.
Ronald Moe
"...another possible way to eat this elephant would be thru SILConverters'
XML Data Converter."
It's nice to know there are high tech solutions to some of these things. But
the problems in my Greek dictionary were created by CC tables. I want to be
able to use Bulk Edit where I can see what the processor is doing and use
the check boxes to eliminate exceptions to the rules. So I'll probably just
wait until the programmers can improve the Bulk Edit tools.
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of Bob & Barb Eaton
Sent: Monday, July 07, 2008 8:32 PM
To: flex...@googlegroups.com
Subject: [FLEx] Re: Bulk edit
//LexExampleSentence//Run
Bob
No virus found in this incoming message.
Bruce Hooley
Thanks for your response John. I suppose we all do tend to want the moon
with a fence around it for sixpence!!
My original thought was that one wouldn't normally put a fullstop at the end
of examples in a dictionary, so therefore I have lots without. But I now
recognise that it is usual to include normal punctuation with examples, and
I was looking for an easy way to do it. I do have multiple examples for many
entries, and they all just list out neatly under one another with whatever
punctuation, or lack of it, there is. I hadn't even got around to thinking
about the translations of the examples yet. The idea of selecting the first
example in each case would select a huge chunk of the examples, but in the
end, it looks like I am going to have to work through one entry at a time on
this one.
Thanks for your help, and greetings from Oz!
Bruce
Bruce Hooley
Bruce
----- Original Message -----
From: <max...@umiacs.umd.edu>
To: <flex...@googlegroups.com>
Sent: Monday, July 07, 2008 11:50 PM
Subject: [FLEx] Re: Bulk edit
>
Beth B
> A better solution would probably be a bulk edit view focused on
> example
> sentences (one row per example). The trouble is, following that
> pattern
> could produce an overwhelming number of bulk edit views, and it
> would take
> a lot of understanding of the model to navigate it.
I'm not convinced there is an overwhelming number of bulk edit views
that are needed. The primary two that I can think of are:
- Examples
- Alternate forms (allomorphs, but hopefully this section will be
expanded to include other kinds of alternate forms)
> To do it really thoroughly would need yet another for bulk edit
> example
> translations, with one row per translation.
Why is this? Is it because one can have more than one Free
Translation (for example) per example?
I was assuming that someone might have multiple translations, but
they would be different types: a free translation, a literal
translation. In practice, I doubt that there would be very many
translations per example. Anyway, I was just assuming that each kind
of translation would just be another column.
But we definitely do need Bulk Edit for both examples and Alternate
forms. The most common reason is if someone wants to do an
orthography change, but there are other reasons too.
-Beth
Craig Farrow
I think missing full-stops are just one example of the generic need to
check examples & definitions for various punctuation problems including
mismatched parentheses, quote marks, capitalisation, and so on. There
will be other things too that contribute to having a well polished (i.e.
proofed) dictionary. One of my colleagues has got a Python script that
runs through his dictionary and checks for matching parentheses in
definitions (along with other sanity checks). At the moment it just
outputs a list of 'bad' entries, and he has to go through and find them
in FLEx to fix them. I think for some of these potential checks --
parentheses included -- an automatic fix isn't possible anyway, so
getting a report like this might be a helpful way to go.
I'm starting to work on a design to put this kind of check, along with
other useful checks/tools into a package for easy use, but in the
meantime I could help you get a Python script going to report entries
that have problems in the examples. Actually, more than just reporting,
I've just got some test code going that adds exclamation marks to the
ends of all the examples*, so we could work on fixing the errors. Are
you up to coding some of the logic if I get the basics working? We could
expand to include some of the other checks that I mentioned above if
they would be useful too...
* Note: I lost any formatting in the example string, and I'm not sure if
the support is in FDO to fully handle keeping that yet... If you don't
do any special formatting in your examples then we don't need to worry
about that (yet!)
Craig.
mark
nice things about configuring the dictionary view is that you can tell
FLEx to put a full stop after each example (or leave it out). Wouldn't
that be more flexible solution than hard-coding the periods into the
example field?
(Of course you'd still need to bulk edit the examples to *remove* any
hardcoded periods...)
Mark
mark
Mark
Alexandre Arkhipov
Is it possible to have a kind of a custom "flag" field to flag the records
you need without altering the original contents? It would also be handy to
filter the records afterwards.
Alexandre
----- Original Message -----
From: "Craig Farrow" <craig_...@sil.org>
To: <flex...@googlegroups.com>
Sent: Wednesday, July 09, 2008 12:08 PM
Subject: [FLEx] Checking punctuation in examples (was Re: Bulk edit)
> ...
Beth B
> I think missing full-stops are just one example of the generic need to
> check examples & definitions for various punctuation problems
> including
> mismatched parentheses, quote marks, capitalisation, and so on. There
> will be other things too that contribute to having a well polished
> (i.e.
> proofed) dictionary. One of my colleagues has got a Python script that
> runs through his dictionary and checks for matching parentheses in
> definitions (along with other sanity checks).
This is one of the things the dev team is in the middle of working on
right now, for the October release. I can't remember how far they've
gotten, but they are working on the following kinds of checks:
- spelling checks (based on open source dictionaries that you can
go out and find and then install, for major languages, or based on
the corpus word list (Words area) for vernacular)
- punctuation checks (they have seen the script Craig mentions)
- valid character checks (can also be helpful for languages that
use ideographs)
Craig, I don't know if the dev team is interested in getting your
help on some of this, but this might be a place where someone like
you (not fully an outsider, but also not fully on the team) could help.
A lot of them are on vacation right now, so the team there is kind of
sparse right now.
-Beth
John_W...@sil.org
The punctuation and valid character checks that Beth mentioned are currently focused on Translation Editor.
The valid character inventory is being stored as part of the writing system definition, so other code could take advantage of this. The actual check is written in a generic way so that Paratext 7 and TE can both use it, so I'm not sure if the API would be useful for general text.
The plan is to store punctuation information in the writing system definition also, but we haven't implemented that yet.
The checks are being written in C# rather than Python. The checks are designed to be independent of most FieldWorks code, so a full FieldWorks development environment is not needed to work on them. We are always open to hearing from those that would like to help with the work - there are some challenges to getting started, so patience and perseverance are required by all involved.
I'm not surprised that formatting information was lost when FDO was used to change text through Python - the formatting information is C++ structures that are then serialized when saved to the database. A more natural C# wrapper for formatted strings (TsStrings in FieldWorks speak) would probably help.
John Wickberg
TE Project Manager
Ronald Moe
" I'm not convinced there is an overwhelming number of bulk edit views that
are needed. "
Actually there is an overwhelming number. I recently made a list of all the
fields that can be repeated (which is one of the underlying problems with
allowing them to be Bulk Edited). I was shocked at how many there were. For
example you can have more than one pronunciation. Currently you can Bulk
Edit the Pronunciation field, but only the first instance. You can get each
instance to show only by sorting on the field. But any process only affects
the first instance. For example if you use click copy it will change the
first instance even if you click on a word in the second line. The
Pronunciation field column is blue but the processes do work on it. This
kind of bizarre behavior needs to be fixed. It is confusing to figure out
what can be Bulk Edited, when, and why these seemingly odd restrictions
apply.
I'm confident the programmers can figure out how to do this. :)
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of Beth B
Sent: Tuesday, July 08, 2008 11:09 PM
To: flex...@googlegroups.com
-Beth
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.4.7/1542 - Release Date: 7/9/2008
6:50 AM
Craig Farrow
That's a good idea, which might save some headaches if the automatic fix didn't work quite right. Writing to a custom field should be possible.
Craig.
7/9/2008 5:27 PM dï, Alexandre Arkhipov pišdimiš:
Ronald Moe
"Why is this?"
Beth is asking why we would need an overwhelming number of Bulk Edit views.
I've written off-line to John Thomson about this, but the subject is
continuing to be discussed on this list. So I think the problem should be
discussed here for the sake of those of you who are concerned. (The
explanation will unfortunately need to be a little long. I'm also not sure
that I understand it correctly from a computational point of view.)
The basic issue is that a dictionary database has a hierarchical structure.
Each time a field can be repeated it creates another level in the hierarchy:
\lx Lexeme
- \sn Sense 1
- - \dx Definition
- - \xv Example (vernacular)
- - - \xt Translation (English)
- - - \xt Translation (English)
- - \xv Example (vernacular)
- - - \xt Translation (English)
- \sn Sense 2
- - \dx Definition
- - \xv Example (vernacular)
- - - \xt Translation (English)
The real problem here is that this is not just a two dimensional hierarchy.
It is three dimensional. I've handle the first dimension by putting each
field on a new line. I've handled the second by labeling each line. I've
handled the third dimension by indenting each level of the hierarchy. Both
Lexicon Edit and the Browse views are two dimensional. Lexicon Edit at least
has some heavy gray lines to separate the Entry level fields from the Sense
level fields (and the Alternate Forms and Gram. Info. Details sections). But
there is almost nothing you can do to make a Browse view three dimensional.
(See below for one thing we could do.)
I wish that we would indent the Lexicon Edit view in order to teach the user
how the data is organized hierarchically. Or we could use more heavy gray
lines. One of the big problems with Toolbox is that the hierarchical
organization of the data was not obvious to the user in any way.
Consequently most users never understood how the data needed to be organized
and never kept their data consistent. At least FLEx imposes an order on the
fields (except for custom fields which unfortunately cannot be reordered by
the user). But the user still is not visually confronted with the structure
of the data. So he never learns (or rarely learns) and so is confused when
he can't do things.
The Bulk Edit tools need to be in a Browse view. Since it is not obvious to
the user that the data is three dimensional, it is also not obvious why we
need Bulk Edit Entries, Bulk Edit Senses, Bulk Edit Reversals, and an
"overwhelming number" of other Bulk Edit views. It is also not obvious why
some fields can be Bulk Edited and others cannot. You cannot Bulk Edit any
field that can be repeated (or at least there are heavy restrictions on what
you can do).
Fortunately there is a way out of our dilemma. Here is what I would
recommend:
1. Indent the Lexicon Edit view to teach the user that the data has a
hierarchical structure and what that structure is.
2. Combine the Bulk Edit views into a single view.
3. When the user wants to Bulk Edit a field, the first thing he has to do is
specify which field he wants to Bulk Edit. This becomes the "Target" field.
4. The program sets up the Bulk Edit view to in keeping with the nature of
the target field. For instance a list field only needs List Choice and
Delete as tool options. A text field does not need the List Choice tool, but
it needs all the rest.
5. For each target field the user can specify which fields he wants to see
and what order they should be in. The program should remember this
user-specified set up so that the next time the user wants to target that
field the program will restore the set up.
6. The program sets up the Bulk Edit view so that the target field is on the
correct level of the hierarchy. For instance if the user wants to Bulk Edit
the Example field, each row represents a different example sentence in the
data. Any field that is higher than the target field in the hierarchy would
have to be duplicated for each row. For instance if an entry had two
examples, the entry level and sense level field would be duplicated:
Lexeme | Definition | Example (Target)
----------------------------------------------------------------------------
---------
bank | Any piled up mass | The clouds stood in banks across the sky.
----------------------------------------------------------------------------
---------
bank | Any piled up mass | The kids slid down the snow bank.
6. Any field that is lower than the target field in the hierarchy would be
handled a little differently. If there is more than one instance of the
field, each instance would be on a separate line. But the higher level
fields would not be repeated. In the following example the Definition field
is the target field, and the Semantic Domain field, which is on a lower
level, is repeated:
Lexeme | Definition (Target) | Semantic Domain
----------------------------------------------------------------------------
---------
love | to want to do good | 4.3.3 - Love
| | 4.3.4 - Do good to
----------------------------------------------------------------------------
---------
love | to like sth very much | 3.4.1.1 - Like, love
| | 3.4.1.1.1 - Enjoy doing something
7. Sorting and filtering would work on the target field and any higher level
fields as it does now. However it would work on lower level fields
differently. For instance if you filtered the example above for a particular
semantic domain (such as 4.3.3 - Love), you would get the following:
Lexeme | Definition (Target) | Semantic Domain
----------------------------------------------------------------------------
---------
love | to want to do good | 4.3.3 - Love
| | 4.3.4 - Do good to
----------------------------------------------------------------------------
---------
adore | to love smb very much | 3.4.1.1 - Like, love
| | 4.3.3 - Love
The reason for keeping all instances of the lower level field is that the
user needs to realize that copying information from a lower level field to a
higher level (target) field is a bit of a problem. The user needs to specify
which lower level information should be copied. Likewise any decision to
modify the target field on the basis of a lower level field may require
taking into consideration all instances of the lower level field.
Well this is long enough. More thinking is needed to work out the details.
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of Beth B
Sent: Tuesday, July 08, 2008 11:09 PM
To: flex...@googlegroups.com
Subject: [FLEx] Re: other Bulk edit views
-Beth
Bruce Hooley
Thanks for your offer of help, but I'm not sure I am up to handling the
logic coding. What would be involved? It sounds like this would be a useful
tool, but maybe not quite far enough along for me to cope at the moment.
I've just about resigned myself to working through entry by entry and adding
the fullstops where necessary. And as I have been doing that I've discovered
one or two other inconsistencies that needed fixing, so maybe it's not all
bad!
Regards and appreciation
Bruce
Bruce Hooley
Mark wrote:
> ...It seems one of the
> nice things about configuring the dictionary view is that you can tell
> FLEx to put a full stop after each example (or leave it out). Wouldn't
> that be more flexible solution than hard-coding the periods into the
> example field?
>
Where does one access that option Mark?
> (Of course you'd still need to bulk edit the examples to *remove* any
> hardcoded periods...)
>
And I think that is the problem. Even if we could add fullstops to each
example, unless I'm mistaken we still can't bulk edit examples to remove
those with double ..
Unless the option you mention would remove fullstops from the examples that
have them, and then turn round and add them to the whole lot??
So I think it is still a manual exercise to keep me out of mischief.
Regards
Bruce
Bruce Hooley
When I am in a stem based view of the dictionary, the subentries (complex
forms??) appear at the margin and a list of them also appears under the
relevant entry. I can get rid of that list by unticking Complex forms in the
Configure dictionary.
In the root based view, the subentries appear indented under the main entry
complete with all the desired information, but then they all appear again as
full entries at the margin with the same information, and I don't seem to be
able to get rid of them.
It seems to me we don't need them in both places--they should be either
indented, or full entries, but not both. Is there a way to get rid of the
full entries and just leave the indented ones?
Bruce Hooley
Ronald Moe
"Is there a way to get rid of the full entries and just leave the indented
ones?"
FLEx 2.5.0.) You should be able to use Configure Dictionary to choose
whether or not you want to include minor entries. However it appears that
there is a bug or else the FLEx team decided you should not be able to
eliminate the minor entries (at least globally). You can eliminate the minor
entries on an entry-by-entry basis using the 'Show Minor Entry' field, but
you cannot eliminate them globally. Anyway here is my description of how the
system is supposed to work:
In a root-based dictionary the general practice is to include each complex
form as a full subentry under the root. When necessary a minor entry is also
included for a complex form when the user would have trouble finding the
correct root. The minor entry would alphabetize where the complex form would
occur, but would merely serve as a cross-reference to point the user to the
correct root entry where the user will find the full subentry for the
complex form. (See below for an example.)
In version 2.5.0 you can use Tools-Configure Dictionary to configure a
root-based dictionary. Click Tools-Configure Dictionary to get the
'Configure Dictionary View' dialog box. In the 'Choose dictionary view to
configure:' box select 'Root-based'. Then in the 'Configure' area scroll
down to the bottom and click on the 'Minor Entry' line. If you click the
check box next to 'Minor Entry' you can choose to include minor entries in
the dictionary or not. [I tried to do this and found that I could not. I
could not uncheck the box.] But this is a global choice affecting all minor
entries. If you check the check box, then click on the plus symbol next to
it to expand the item, you can select which fields to include (or exclude)
from the minor entry. Since a minor entry is supposed to be short and merely
function as a cross-reference, you should probably uncheck most of the
fields.
In version 2.5.0 you also have the option of deciding which roots to show
the full subentry under. You do this in Lexicon Edit-Entry view in the 'Show
Subentry under' field. You can use this field to control on an
entry-by-entry basis where you want the full subentry to occur. You can
choose one root (of a compound or phrase), or you can choose to duplicate
the full subentry under more than one root (or even an affix if you wanted).
You can also decide on an entry-by-entry basis whether to include a minor
entry for a complex form. You do this in the 'Show Minor Entry' field.
What we don't yet have (someone please correct me if I'm wrong) is the
ability to create minor subentries under a root. For instance if you wanted
to put the full subentry for 'blueberry' under 'berry', but also wanted a
minor subentry under 'blue', you cannot do this. You can create a
cross-reference using the 'Cross References' field. But this is not ideal.
Using these features, you could create the following entries.
fore N the front part of something
see V to perceive something using the eyes
unforeseen (comp.) Adj a word describing an event that no one
thought would happen
unforeseen comp. of fore, see
You could eliminate the last entry (the minor entry for 'unforeseen') if you
wanted.
I would like to be able to produce something like the following root-based
dictionary. However accomplishing this using the current features in FLEx is
not possible.
fore N the front part of something [main entry]
forearm N the lower part of the arm [subentry]
unforeseen (see under 'see') [minor subentry]
see V to perceive something using the eyes [main entry]
unforeseen (comp. of fore, see) Adj a word describing an
event that no one thought would happen [subentry]
unseen Adj not noticed or seen [subentry]
unforeseen (see under 'see') [minor entry]
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of Bruce Hooley
Sent: Wednesday, April 08, 2009 9:35 PM
To: flex...@googlegroups.com
Version: 8.0.238 / Virus Database: 270.11.47/2047 - Release Date: 04/08/09
05:53:00
Allan Johnson
Yes, I believe so. This was doable in the version I was using a year
ago. I haven't tested this in a more recent version but assume that the
functionality is still there. In the Root based view you can get rid of
most of the unwanted full information in the entries at the margin just
by unchecking "Senses" under "Minor Entry". I've usually configured it
to show only the headword of these minor entries. I haven't tried
getting rid of the entire minor entry including the headword. If you
need to do that as well, you might try unchecking "Minor Entry". Though
if I understand Ron's note correctly, he found that check box to not be
working.
Here's an abbreviated summary of the Root based and Stem based views,
showing the essential differences between the entry parts by leaving out
some details that they all have in common, and showing the default
settings of the check marks. Note that in Stem based view there are two
possible locations for senses to be displayed, while in Root based view
there are three possible locations. What you do with those "Senses"
check marks will control where most of the bulk of your entries shows up
- whether in main entries at the margin or in subentries (or in both
places, or in neither of them)
Root based
(x) Main Entry
(x) Headword
(x) Senses
(x) Subentries
(x) Headword
(x) Entry Type
(x) Senses
(x) Minor Entry
(x) Headword
(x) Primary Entry References
(x) Senses
Stem based
(x) Main Entry
(x) Headword
(x) Primary Entry References
(x) Senses
(x) Complex Form References
(x) Minor Entry
(x) Headword
(x) Primary Entry References
( ) Senses