multiple dialects or clanlects - help!

[Bethia Blond]

Hi folks,

I have been tasked with creating a single bilingual dictionary that encompasses 3 dialects, each of which covers a further 4-5 clanlects (14-15 clanlects in total). My workplace has been compiling this database for at least 5 years, drawing words from numerous 100-to-200-year-old bilingual dictionaries/wordlists. The database currently has around 8,000 entries, which have a VERY "flat" structure, with 1 entry for each reference for each dialect/clan/inflected variant.

I have been given the rather monumental task of consolidating these entries into "tiered" entries which each include all of the clan/dialect variants and inflections associated with a particular "word". I am currently planning how to re-structure the entries and am really struggling to think of how I can neatly structure:

     (a) multiple inflections,

     (b) multiple dialect/clan variants, and

     (c) multiple senses (including when the meaning of a particular word varies across dialects/clanlects),

without substantial repetition!!

Any neat suggestions on how to resolve this? All I can think of is to finely comb out all of the polysemes where meanings don't match up across different dialects/clanlects, into different entries using homonym numbers, and then group all of the inflected variants at the top of each entry, then list sense/meaning information, and then all of the dialect/clanlect variants at the bottom.

Many thanks,

Bethia

[John R. Rennison]

Dear Bethia,

Please let me take your queries in the order (b), (c), (a).

Ad (b)
This is a problem that we are currently confronting in Koromfe, first of all for the two major dialects, but eventually for all geographic and social variants. You might like to take a look at my (mainly) monodialectal dictionary of Lorom Koromfe on
https://www.univie.ac.at/linguistics/personal/john/Dict_EN.pdf or https://www.univie.ac.at/linguistics/personal/john/Dict_EN.docx .

Unfortunately, there's no way to avoid listing all known variants of a word separately as main entries, each with a reference (I use "→") to the main entry for that word. The main entry must also list all known variants as sub-entries. There is no way to avoid this duplication, since a) the dictionary user must be able to find EVERY word alphabetically, and b) you need to document all the occurring variants of a word in one place.

I have a CC script that automatically generates all the type-a) main entries from the sub-entries of type b) main entries. This saves a lot of work!

In my dictionary, each sub-entry of a word (i.e. each derived and/or inflected word form) has its own (optional) \ps field, separate from the morphological category of the main word entry. I am thinking of extending such \ps entries to include a short "lect code", so instead of

a zãŋfɔɔndɔ ordinal numeral human sg.

I would have

a zãŋfɔɔndɔ ordinal numeral human sg. - Ka.

where Ka. is the abbreviation of Karɔ, one of the two major dialect areas.

Ad (c)
For multiple senses I already have a \de field for sub-entries which is distinct from the main entry "definition English" field (\mde).

Ad (a)
I know no way of avoiding listing all inflections (and ?some ?all derivations) from a word stem. Sorry.

If you find these ideas potentially useful and would like a copy of my Koromfe Shoebox/Toolbox system, cc-script and pitifully sparse documentation, please let me know. In any case, good luck with this venture.

All the best,
John

--
You received this message because you are subscribed to the Google Groups "Shoebox/Toolbox Field Linguist's Toolbox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shoeboxtoolbox-field-ling...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/e8bece00-79fe-45f3-a5da-9be8c4327b75n%40googlegroups.com.

[ToolBox Support]

Hi, Bethia,

I really appreciate John offering his experience with a multi-dialect dictionary as I know very little about the ways to organize such data. Thanks, John!

I just want you to know that "I'm here", and if you need help with reorganizing your data, I'll be glad to help you. John mentioned a CC process. CC is a really great tool for reordering data. I'm pretty good at CC myself and will gladly assist you with any variations of his CC process that are needed, or with any innovative thoughts you have about organizing the data.

You might find the Filtering feature of Toolbox useful, as well as the Browse -- both let you view subsets of the data. In the case of filters, you can export the specific data that you have filtered. If you have any questions about these features, let me know. I'll be glad to help.

Also, I know you may need help getting all this information printable or online. Again, I'm here.

Karen

Toolbox Support

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/cff912b1-03cb-039b-d6df-87384b7ef49d%40univie.ac.at.

[Bethia Blond]

Hi John,

That is so helpful, thank you! I notice that you have managed to print out the French, German and English definitions all at once, in different colours -- how did you manage to do that?? What fields did you use for the different language definitions? I played with using the English/national/regional fields for the three main dialects I am working with, thinking that I might be able to get them to print out the way that you have with different colours, etc., but I couldn't get them to print out all at once. Would be great to know how you did that.

A related problem which I haven't even thought about yet is that we also want to be able to print out 'dialect dictionaries' and 'clan dictionaries' which only contain the information relevant to each dialect/clan - maybe if we used different fields for each dialect at least (if that is how you are making all of the different languages different colours?), in combination with filters, we could simplify the editing process a bit for after we have exported to Word.

I imagine we could have individual entries for each variant, link these all back to a "main entry" like you say, and just include dialect info for each word variant in the variant/minimal entry, (possibly also put the inflectional morphology for variants there too?).

Regarding (c) - thank you!!! Again!! I'm interested to hear what you mean by the mde and de fields -- is that within the same headword, or within subentries? Are you using the se field for word variants from from different languages/language varieties which have slightly different meanings? Or I am not understanding you properly? The difficulty I am having is with instances like the word 'boko' in one dialect meaning a specific type of grass, and in a different dialect meaning any species of grass. So there are two senses of the same word, but each sense is relevant for a separate dialect. A more complex/frustrating example is that a lot of homonymy occurs where one word refers to a thing, and also the substance produced by that thing - but (really cool but frustrating from the pov of Toolbox) this can also occur across dialects at the same time as dialectal variation in pronunciation. So there may be 5 clan/dialect variant pronunciations which each occur with some combination of clearly related senses, and an additional pronunciation that ONLY means a sense which is different again from those already listed. So I either (i) bundle it into the complex entry even though the headword is different AND the sense of the word is different from all of the others (keeping the variants as one nice neat bundle of clan/dialect variations, even though the final one doesn't quite fit as well as the others), OR (ii) I make a completely separate headword which is structurally entirely separate from the other much larger bundle of related dialect variants - possibly with a cf bakc to larger bundle of dialect variants (annoying to have a related dialect variant kind of orphaned on its own like that, when it's clearly related to this massive bundle of other variants!). I really want to tie this variant into that bundle of clan/dialect variants with meanings and pronunciations which are clearly, obviously related - but it's just sort of slightly too far away from the 'centre' of that bundle to neatly fit into the single, complex entry that the other 5 variants are fitting into. This actually occurs frustratingly often. Any suggestions?? Nothing for it but to put it in a completely separate entry (with cf back to larger complex entry?) or embrace the messiness of shoving it into the same complex entry as the others, even though it doesn't quite fit?

Re (a) -- that's fine, I appreciate knowing at least someone else has put up with the lengthiness/messiness!!

Many thanks,

Bethia 

[Bethia Blond]

Hi Karen!

One problem which has not been an issue up until now because the structure is so "flat", but which WILL become an issue, is as follows.

We are using a single database to create whole-language, dialect, and clan dictionaries. Up until now, we have been using filters to draw the clan/dialect dictionaries out of the overall database. This has worked well because each entry only has information about 1 clan/dialect variant, so if we filter using the "ue: Northern Dialect", for example, it doesn't export any information about other dialects because there is no information about other dialects in those entries. HOWEVER. As we consolidate multiple entries into single, complex, "tiered" entries, each entry will start to have information from multiple dialects/clans. I presume this means that when we export using our existing filters, we will be exporting ALL of the contents of the chosen 'export' fields, for all of the entries which have ANY information in them about the clan/dialect we are looking for. This will mean, I imagine, that a much higher percentage of the total entries will be exported (as the total number of entries will shrink from around 8,000 to possibly around 3-4,000), AND that there will be a lot of sense, clan, subentry, etc data included in that export which occurs in the filtered entries, but which actually relates to other clans/dialects. I currently have no idea how to deal with this neatly/quickly, other than (1) extensive Word-doc editing post-export every time we make a clan/dialect dictionary (not the end of the world but very time-consuming); or (2) making 14 versions of all of the fields we regularly use, allocating them to each of the 14 clans, and then applying a filter AND exporting only the fields for that relevant clan/dialect, to create a word doc which hopefully is mostly only the info relevant for that clan/dialect. Obviously neither of these options are particularly amazing. As I mentioned in my message to John, we could maybe use the v/n/r fields for the three of the respective 3 dialects (in combination with filters), IF we have the OPTION of exporting the 3 v/n/r field-sets separately OR simultaneously (for the bigger 'whole-language' dictionary)... (We currently don't use the r/n fields for anything else.) That might simplify the editing process a bit for after we have exported to Word at least. Although that has its own complications and thinking about it again I think that actually would not work either... aaahhh!!!! I dunno. Do you have any ideas??

Many thanks,

Bethia

[John R. Rennison]

Dear Bethia,

I’m glad my message was of some use – at least for the colours. This message is only a reply to the first paragraph of your message to me. I need to think for a while about the other stuff – but I will get back to you soon.

At the moment I only have colours for the “definition” fields (i.e. not for different lects), so I would imagine that you probably won’t need them much in Australia. (I added French because it is the national language of Burkina Faso, where Koromfe is spoken, and German because it is the language of my university.)

Anyway, I DID use the English/national/regional fields. In my MDFDict2.cct file I replaced the line

    if(de) '\de ' out(de) '|fs{.}' nl endif

with

    if(de) '\de ' out(de) '|fs{;}' nl clear(de) endif
    if(df) '|fl{fr: }|fn{' out(df) '}|fs{;}' clear(df) nl endif
    if(dg) '|fl{dt: }|fr{' out(dg) '}|fs{.}' clear(dg) nl endif

and added analogous lines for examples, including the new fields “\xps Example part of speech” and “\xnt Example note”:

    if(xv) '\xv ' out(xv) clear(xv) endif
    if(xps) '\xps ' out(xps) '|fs{;} ' clear(xps) nl endif
    if(xe) '\xe ' out(xe) '|fs{;}' nl clear(xe) endif
    if(xf) '\xf ' '|fl{fr: }|fn{' out(xf) '}|fs{;}' clear(xf) nl endif
    if(xg) '\xg ' '|fl{dt: }|fr{' out(xg) '}|fs{.} ' clear(xg) nl endif
    if(xnt) '\xnt |fl{[Note: }' out(xnt) '|fl{]}' clear(xnt) nl endif

These lines change the font style of the French “definition” and “example definition” fields to “f_national” and the font style of German-language fields to “f_regional” when you export to RTF. The English fields come out with the font style “Definition (E)”. In Word, you can change the colours of these fonts as you please.

The same approach could be used for colouring lectal variants, BUT it’s tricky. What colour do you use (or how do you mix the colours) when, say 2 out of 3 major dialects use a particular form? Or 12 out of 15 clan-lects? I am faced by a situation quite contrary to yours; there is still very little data on any of the other dialects. So really I have only been mulling the problem of marking lectal variants in theory, not in practice. But I’ll be more than happy to cooperate with you to work out an adequate system for use with Shoebox/Toolbox.

For now, I need to clean up my documentation of the dictionary structure so that I can send it to you, along with my revised .CCT files.

All the best,
John

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/ce069fef-c405-4657-ac97-167d2d910633n%40googlegroups.com.

[Tony Naden]

And      

Nikiéma, Norbert / Jules Kinda [eds.] 1997. Dictionnaire Orthographique du Moore / Moor gom-biis no-tũur gʋlsg sebre. n/p (Ouagadougou) : Sous-commission nationale du moore

shows where you can get if you try to amalgamate too much variation.  Might it be better to separate out a dictionary of abstract roots with the common other-language glosses, cultural and scientific info., &c. to which you cross-refer, from a list of occurring forms.  How the dialect and clanlect identification of the occurring forms is indicated, and how you insert these indications, depends on how the material you are starting with is organised.  The TOOLBOX export function using selection, renaming, and reordering  of fields can achieve quite a lot.

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/bdc0ecf9-762d-1659-22ad-a122eab5a45b%40univie.ac.at.

--

Address: "Lost Marbles", 31, Reading Road,
Pangbourne, Berks., RG8 7HY  -

Tel.: 01189842368

Most Holy God and Father, hear our prayers for all who strive for peace

and who fight for justice.

Help us today to remember the costs of war, to work for a better tomorrow;

and, as we commend to you lives lost in terror and conflict,

bring us all, in the end, to the peace of your presence;

through Jesus Christ our Lord.

Amen.

[ToolBox Support]

Dear Bethia,

First, forget about trying to squeeze into MDF. It doesn't fit your situation. Some while ago I created an alternative that is more flexible. (The problem is I haven't documented it very well so it's not on the website.) This means you can add other fields -- not just de, dn, dr but something like den, dey, del, or deue, devn, de_xy -- etc. whatever you need.

Second, how about something like the semantic domain structure for your multiple language/dialect/clan situation? I'm thinking of something like \dia Eng:US:s for "Southern US English".

Furthermore, since you already have the information clearly tagged in the individual entries, the combining can be done with CC, so you don't have to struggle with doing the combinations manually (and all the consequent errors).

This more detailed tagging would allow requesting just a specific dialect or a broader grouping with tags (automatically generated) for the different clans within a dialect.

More can be done. Think about what you want, not what MDF has been restricting you to. Then we need to discuss the details.

Karen

Toolbox Support

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/CANW%2Bcj7qmL8_uMW5qHrtP91w7VokzQd3eNQop-ZqxY5UYxsNAQ%40mail.gmail.com.

[Bethia Blond]

Hi John,

Thank you again for your quick response. I am pretty much a total beginner to playing with CC and the export process -- but understanding it is a pretty high priority! I will keep that 'code' in mind for when I understand how to insert it better, thank you.

Regarding this paragraph -- "The same approach could be used for colouring lectal variants, BUT it’s tricky..." -- I was thinking about this. I found an example (Yugambeh-Bundjalung Dictionary (dalang.com.au)) where they have colour-coded for dialect and then tagged for 'clan'. (but they haven't gotten back to me about how they worked with their data to get it to that stage, though, and I suspect that they have leant on editing the final document rather than editing it structurally/procedurally through MDF/CC, as the marking/structure in their pdf seems a bit inconsistent.) So I was thinking that could work and then we could also expressly tag for dialect & clan with something like 'DIA-CLN'. I was thinking maybe I could group all of the clan variants/related inflections together (tagged for clan, colour-coded for dialect), and then list all of the senses and at the end of each sense tag with all DIA-CLN's which apply for that sense, AND THEN colour-code ONLY the DIA-CLN tag at the end of each sense. What do you reckon?

I still haven't worked out a way to structure that en masse using tailored exports/Toolbox structures, but I was thinking I could mass-replace all of the DIA-CLN tags with colour-coded DIA-CLN tags after I do the export (still takes a bit of time but way less than colour-coding the tags completely manually).

A separate issue is that it's a language which has not been significantly standardised so I am not sure how I/we are going to decide what variants the headwords should represent, but I'm leaving that for later down the line.

I don't know if (and maybe this is a question for Karen?) it's possible, if I change the hierarchy of fields within Toolbox so that all dialect-specific fields sit under the fields which specify clan/dialect, to colour-code those fields in the export based on (range-set) values within the clan/dialect field?? I am starting to learn some coding generally (as a general up-skilling), so if there's a specific place I can go/look to understand the context of the MDFDict2.cct file, that'd be amazing.

Many thanks (again) John!

Bethia

[Bethia Blond]

Hi Karen,

I think definitely the possibilities that I am considering are limited by my understanding of what is/isn't possible in Toolbox - it would be really interesting to have a think based on what is ACTUALLY possible. I feel like a verbal conversation at some point would be amazing, I don't know if you do that?? Even if it's just a "this is possible, that's not possible, that might be possible if x" & then I can go research/work out how to do it? Especially to explore ways to export individual dialect/clan information without arduous editing in Word each time.

I'm keen to learn more from the existing documentation about how to modify the export process, so hopefully I'll understand it more in a few weeks, as I've been able to go through some more stuff & some cherry-picked learning-to-code (python??) educational material online so I understand better what to change/what not to change in the cct documents.

I have also custom-made a few of my own fields that I'd like to export (particularly a 'cln' field for clan). 

I don't know if it's possible, if I change the hierarchy of fields within Toolbox so that all dialect-specific fields sit under the fields which specify clan/dialect, to colour-code those fields in the export based on (range-set) values within the clan/dialect field?? If there's anywhere you'd recommend to learn more about the coding language (???) that the cct documentation is in, to better understand the context of the MDFDict2.cct file (so I don't break it accidentally & can play around with different things), that'd be amazing. I assume that modifying the cct documentation works in a similar way to the 'CONCATENATE' function in excel, so e.g. field 1 and field 2 could be exported as --> field 1 + " (" + field 2 + ")" --> to create something like "field 1 (field 2)".

Also can custom/MDF fields which are hierarchical be made to export in the order relevant to their hierarchy?? e.g. if the hierarchy is:

• field 1
  • field 2
• field 1
  • field 2

can I set it so that the export is field 1 field 2 field 1 field 2, not field 1 field 1 field 2 field 2? I imagine that's possible once I understand the cct-modifing process better?

I just want to try plan it all out before I go through the whole process of combining different entries, so if there's any extra changes I need to make I can make them as I'm changing everything else!

Thank you so much Karen!!

Bethia

 

[Bethia Blond]

Thanks Tony, I'll have a look at that!! :)

[Bethia Blond]

Just saw the CC documentation, looking at it now!!

[John R. Rennison]

Hi Bethia,

Many thanks for sending the link to the Bundjalung dictionary. To get an
output like that, the only thing you can do is to mark each entry in
Word and give it the appropriate colour (or a character style, say, with
the name "DIA-CLNxy", which contains the desired colour). Using your
historical material, I don't think there's much else you can do. Or is
anyone actually doing fieldwork on your language? If yes, then I need to
do a rethink. If not, then I wish you good luck with all that formatting.

All the best,
John

[ToolBox Support]

Hi, Bethia,

The existing CC documentation is pretty poor. I have a few basic lessons out there, and the full reference manual. The first bit is too little for your needs and the Manual is probably too much to comprehend without more examples. I am trying to work on more example tables.

CC is actually quite user friendly and the processes can feed each other. My alternative to MDF has about a dozen CC tables. Just one little step at a time... Export processes can link together, so you only start at one point, and the rest feed each other automatically. 

As for having verbal, one-on-one communication, like with Skype, I certainly do that. I'm very glad to get together with you face to face so we can discuss this further. I'm not sure I want my Skype ID totally public, so I will send you a personal message, and we can arrange a time. I am in the US, in the Central Time zone, but I work with people all over the world, so I don't keep "office hours". I work from home and I can nap as needed to meet with you in Australia at a time that works for you.

I'm so glad other folks are chiming in, too. Thanks, John and Tony! You bring levels of experience that I don't have.

--Karen

--
You received this message because you are subscribed to the Google Groups "Shoebox/Toolbox Field Linguist's Toolbox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shoeboxtoolbox-field-ling...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/bcc0c5b5-3df8-a22b-405b-a2da1bd47b8d%40univie.ac.at.

[ToolBox Support]

A comment about color in a Word document.

When Toolbox exports, the RTF process (whether via MDF or a "plain" RTF export) tags fields with a style which is the same as the Field Name of the Toolbox field.

In Word, then, choose Styles, which will provide a list of the style names -- those from Toolbox and some of Word's own.

When you click on Modify, Word will present a dialog box with all sorts of options.

I usually include Bold with a color change -- otherwise it tends to be kind of pale. But you'll have to experiment.

Be sure to click on "New documents based on this template" or the change won't come through the next time.

Anyway, this is the result with an otherwise unformatted dictionary.

Highlighting (background color) also can be done, but it takes a different approach. I recently put it into a macro.

You might be interested in a document I recently added to the Toolbox website named

Creating a Formatted Document from Toolbox 

and its companion

Adjusting the Appearance in Word

They go into all the details. (Though right off, I don't remember if I mention color...)

Karen

[ToolBox Support]

Hi, Bethia,

I realize I never responded to most of your May 31 message.

You said:

I'm keen to learn more from the existing documentation about how to modify the export process, so hopefully I'll understand it more in a few weeks, as I've been able to go through some more stuff & some cherry-picked learning-to-code (python??) educational material online so I understand better what to change/what not to change in the cct documents.

There is some documentation on the MDF process, but it assumes you know CC. Python has value as a language, but not for the Toolbox export processes. You manipulate Toolbox data with anything, since it's plain text. But CC is built into Toolbox. So I'm glad you've found the CC documentation. I will send you my MDF substitute, which is much more open to having extra markers and to adding extra steps. And we can discuss the steps I broke it into and that will help you learn CC. 

You said:

I have also custom-made a few of my own fields that I'd like to export (particularly a 'cln' field for clan). 

That's a big hassle with MDF, and hardly any issue at all for my more customizable approach.

You said:

I don't know if it's possible, if I change the hierarchy of fields within Toolbox so that all dialect-specific fields sit under the fields which specify clan/dialect, to colour-code those fields in the export based on (range-set) values within the clan/dialect field?? 

I'm not sure I see what you are wanting here. See my comments on color in Word that I posted yesterday. You can color-code any field that you export to Word. In particular I'm not understanding what hierarchy has to do with it. (Some days I'm smarter than other days...)

You said:

If there's anywhere you'd recommend to learn more about the coding language (???) that the cct documentation is in, to better understand the context of the MDFDict2.cct file (so I don't break it accidentally & can play around with different things), that'd be amazing. I assume that modifying the cct documentation works in a similar way to the 'CONCATENATE' function in excel, so e.g. field 1 and field 2 could be exported as --> field 1 + " (" + field 2 + ")" --> to create something like "field 1 (field 2)".

I was glad you said you'd found the CC documentation. You will see that the CC process doesn't look like the Excel process.

You said:

Also can custom/MDF fields which are hierarchical be made to export in the order relevant to their hierarchy?? e.g. if the hierarchy is:

• field 1
  • field 2
• field 1
  • field 2

can I set it so that the export is field 1 field 2 field 1 field 2, not field 1 field 1 field 2 field 2? I imagine that's possible once I understand the cct-modifing process better?

You can certainly get the fields to be interleaved as 1 then 2, then 1 then 2 using my custom approach. It can be done in MDF, too, but it would be harder. It's not really through the hierarchy but through the CC table being encoded to be aware of the need to interleave. Frankly, that's simpler than bunching everything that's the same together, or at least no harder.

You said:

I just want to try to plan it all out before I go through the whole process of combining different entries, so if there's any extra changes I need to make I can make them as I'm changing everything else!

I will send you my replacement of MDF. It has steps that can be included or excluded, and we can add more. We can discuss the details of each step (and maybe I'll even get some intelligible documentation out of the process!) 

If anyone else is interested in the package and the discussion, let me know!

Karen

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/48e0435b-295b-4b9d-918f-d8730935e330n%40googlegroups.com.

[Bethia Blond]

Hi John,

This particular dictionary is straight historical texts :) Yes, I was hoping to find a way around formatting it all manually. I don't mind changing the structure of all entries within Toolbox (if necessary), but I dread the thought of weeks of editing every single time we do an export. I really hope I can find a way around it!! Thanks for all of your help & advice.

Kind regards,

Bethia

[Bethia Blond]

Thank you, Karen! I did have a look at those two documents, yes, and got rather excited about the changes that seemed possible with CC (I'd assumed before then, that CC referred to the 'consistency checking' feature and had passed over the documentation about it). I'll message you about Skype times :)
Many thanks,

Bethia

[Bethia Blond]

Marvellous!!!! Thank you so much, Karen!!! I look forward to talking with you in more detail about it.

I will try to read through all of the CC documentation today/over the weekend. Very exciting!

Re: the hierarchy thing - maybe I'm getting stuck on one particular way of approaching this, but basically within each \lx entry there will be several sets of field which relate to clan and dialect - basically, I want these sets of fields to be structurally similar to the example/lexical function/paradigm 'bundles', in that I want variant+associated inflectional forms related to each dialect to sit together in a bundle, and I want each of those bundles to be tagged with a dialect/clan classification. The clan and dialect classification is made up of two separate fields, ue (which we are using for dialect) and the field ('cln') which I have created for the 'clan' classification. Both of those fields would be range sets -- ue would have 3/4 allowable items (3 dialects and I suppose probably an 'unknown dialect' category), cln would have 14 allowable items (the 14 different clan names). Ideally, I'd like all of the clan/dialect-specific information (clan name/abbreviation, variant form & associated inflections) to be colour-coded as orange/green/blue, according to which of the 3 dialects that bundle is associated with. And ideally I'd like this colour-coding to happen automatically. To be continued! I'll create a mock-up of what I'm thinking (thanks to this conversation & especially your and John's input!!) that final output should look like.

Many thanks,

Bethia

[ToolBox Support]

Hi, Bethia,

You said:

I will try to read through all of the CC documentation today/over the weekend. Very exciting!

I'm glad to answer any of your CC questions. And glad to teach you any of CC that you want to learn. It's a very powerful tool.

You've given a bit more detail about your desired output in your message and I'd like to reply to it.

Re: the hierarchy thing - maybe I'm getting stuck on one particular way of approaching this, but basically within each \lx entry there will be several sets of field which relate to clan and dialect - basically, I want these sets of fields to be structurally similar to the example/lexical function/paradigm 'bundles', in that I want variant+associated inflectional forms related to each dialect to sit together in a bundle, and I want each of those bundles to be tagged with a dialect/clan classification. 

This can be done -- just as the examples and lexical function and paradigm bundles are done. The "understanding" of the hierarchy and the bundling is purely in the MDF CC tables. But similar structure and bundling can be done in other tables, like the custom set I sent you.

The clan and dialect classification is made up of two separate fields, ue (which we are using for dialect) and the field ('cln') which I have created for the 'clan' classification. Both of those fields would be range sets -- ue would have 3/4 allowable items (3 dialects and I suppose probably an 'unknown dialect' category), cln would have 14 allowable items (the 14 different clan names). 

This sounds like good organization. It reminds me of the way the Semantic Domain information is coded as two fields. It sounds quite workable to me.

Ideally, I'd like all of the clan/dialect-specific information (clan name/abbreviation, variant form & associated inflections) to be colour-coded as orange/green/blue, according to which of the 3 dialects that bundle is associated with. And ideally I'd like this colour-coding to happen automatically. To be continued! I'll create a mock-up of what I'm thinking (thanks to this conversation & especially your and John's input!!) that final output should look like.

I don't see why that can't be done. At least, as long as you're willing to call executing a macro "automatically". It will be very useful to see a mock-up -- and to see the data it comes from, please. What I'm thinking at this time is that each dialect gets a special tag that will turn on its color. CC would add the tag. I'm sure the color can even be specified in the RTF file, but I'll have to look into the RTF specification to find out how to do that. I know it can be done with a macro. I did that recently for someone else.

By the way, I've been assuming Word all along. But something you said elsewhere made me wonder if you want an online dictionary. Toolbox's XML does know about hierarchy, and colors can be specified in the CSS. (Note: Save the file in Toolbox as XML. The XML export process was written by someone else and doesn't do the full hierarchy.) We can talk more about this if it's something you are interested in -- either instead of or in addition to a paper/PDF printout. Take a look at the Tlingit dictionary we link to on our website. That was (is) a very non-MDF dictionary with dozens of verb forms. You don't want the online structure she wanted for it, but that dictionary has hierarchy and then some in there.

So be encouraged! The more I'm understanding what you want, the more possible it is sounding.

Karen

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/f70cb696-bb89-49de-baf7-193c3af0ee67n%40googlegroups.com.

[Tony Naden]

The rtf styles can be given a colour in the formst.

To view this discussion on the web visit https://groups.google.com/d/msgid/shoeboxtoolbox-field-linguists-toolbox/CAEgRS93EGCtxP2Wnd9yfJ902k4zw7HM9oS0vY56ebjp1YnYKXA%40mail.gmail.com.

[Bethia Blond]

Thanks Tony!