Language Forge » LF Dictionary

so now all models have use the same field settings, and there are two new types of field not exist in WeSay's configuration: "NewMeaning", "NewExample"

keep open, problems in #1 still remain.

The way I think of it, is that the Field settings under the Field tab in the UI define the arrangement that would appear in every instance of the dictionary control. The individual tasks which contain instances of the DictionaryControl then modify this, usually only by determining what should be visible.

e.g. The PartOfSpeech Task would be hiding everything except Lexeme, Meaning, and Part of Speech.

maybe something wrong from very beginning, in entry control, there are two parts(from what I learned from src).
1. the word /meaning: read inputsystem setting from words entries file which attached to word itself.
example: thai-food.lift

    <entry
        id="chùuchìi mǔu rɔ̂ɔp_dd15cbc4-9085-4d66-af3d-8428f078a7da" 
        dateCreated="2008-11-03T06:17:24Z" 
        dateModified="2009-10-12T04:05:40Z" 
        guid="dd15cbc4-9085-4d66-af3d-8428f078a7da">
        <lexical-unit>
            <form
                lang="IPA">
                <text>chùuchìi mǔu krɔ̂ɔp</text>
            </form>
            <form
                lang="th">
                <text>ฉู่ฉี่หมูรอบ</text>
            </form>
        </lexical-unit>
        <field
            type="literal-meaning">
            <form
                lang="en">
                <text>Chuchi curry pork crispy</text>
            </form>
        </field>
        <sense
            id="df801833-d55b-4492-b501-650da7bc7b73">
            <definition>
                <form
                    lang="en">
                    <text>A kind of curry fried with crispy pork</text>
                </form>
            </definition>
            <illustration
                href="IMG_0214.JPG" />
        </sense>
    </entry>

2. the pos,new meaning and new example: use inputsystem setting from setting.

So what is it should look like?

Looking at this example:

            <form
                lang="IPA">
                <text>chùuchìi mǔu krɔ̂ɔp</text>
            </form>

lang="IPA" is an incorrect tag, it should be lang="th-fonipa". That would be the BCP47 tag. Later versions of WeSay would migrate this data to something like "qaa-x-IPA" (an automated migrator could not know that it was supposed to be th-fonipa).

For the dictionary control let's consider a few design requirements:

1) Ordering of the controls
This can (and is) hard coded.

2) Visibility of the controls
This should be controlled by the left hand side check boxes in the Settings | Fields tab.

3) Ordering of text boxes in a multi text control
This should be controlled by the order of the check boxes on the right hand side in the Settings | Fields tab.

4) Visibility of text boxes in a multi text control
This should be controlled by the check state of the check boxes on the right hand side in the Settings | Fields tab.

I think it is fine for the client to display the fields in the order given by the server. The server should read the data and apply the above logic. The data may well contain data that is not ordered as per the configuration. That is fine. Order does not matter in the xml lift file. The server code should impose the order and visibilty according to the configuration.

In the lang="IPA" example above, given that the config calls for th-fonipa, the IPA tagged data would disappear. So for this lift file, we should manually repair it by doing a search / replace lang="IPA" => lang="th-fonipa".

so I don't need to do a hard code re-mapping in code, right? you will "manually repair it by doing a search / replace lang='IPA' => lang='th-fonipa'"?

Xin Zheng wrote:

so I don't need to do a hard code re-mapping in code, right? you will "manually repair it by doing a search / replace lang='IPA' => lang='th-fonipa'"?

right.

I've now done this in the /var/lib/languageforge/... directory