I use Tai-lo when I write for myself, although of course I have no problem whatsoever reading POJ seeing as Tai-lo is based on POJ. In my opinion Tai-lo has a number of small advantages. Most of these are personal taste, but I think for this kind of project, Tai-lo has one objective advantage over POJ, which is precisely the one that is addressed in chapter 3 of the article you linked: There are numerous versions of POJ and although the differences are rather small (for example in the placement of tone diacritica, but also things like the placement of the nasalization marker when combined with the glottal stop -h), they can make database queries very difficult. You would either have to write a script which catches all possible spellings or write out a set of spelling rules for the user to follow. That latter way is how this (http://210.240.194.97/iug/Ungian/soannteng/chil/taihoa.asp) and this (http://taigi.fhl.net/dict/) database work, but it might be difficult to inform the user of such rules in Pleco. For Tai-lo this problem is pretty much non-existent because there is only one version (well, the case sensitivity is no clearer than in POJ, but seeing that Tai-lo doesn't use -N as a nasalization marker, you can just do case-insensitive queries without issues).
I guess you could call it an attempt on soft standardization. The ministry does publish the lists and the dictionary, and quite possibly it is also responsible for the "characters only" policy. However the characters themselves are not decided on by ministery officials but by conferences of scholars (although I can't tell you who decides on who participates in those conferences to be honest). The MoE set is not enforced in publications, so authors can use whatever way of writing they prefer. The only possible exception are textbooks in public schools (and even there I'm not sure. I've seen two or three and they used the MoE set and Tai-lo, but it may not be obligatory. I do know that teachers are not prohibited from using other ways of writing in class, though). The MoE characters and Tai-lo are obligatory in the official Taiwanese language tests which have to be taken in order to get the qualification for steaching Taiwanese in public schools and (as far as I know) also for certain types of government officials.
Interesting that you know some Taiwanese but only limited Mandarin; you don't meet many people like this anymore (especially outside missionary circles). Seeing as you seem particularly familiar with the Maryknoll Society's work, I guess you take classes with them? That wouldn't happen to have been in Taipei and within the past year? If so, it's actually possible that we have met before
Ah, I see how the MoE dictionary is of limited use to you then... I'm much hoping that it is pioneer work which might clear the way for more dictionaries to be implemented into Pleco, though. Personally, I would be most interested in the Taiwanese-Japanese dictionary (the second of the two linked above), simply because it is just massive
Wow that was quick! It's late in the evening where I'm situated, but I'm going to have a detailed look at it tomorrow
Wow that was quick! It's late in the evening where I'm situated, but I'm going to have a detailed look at it tomorrow
As for the remaining issues, it seems the diacritics issue is Pleco having problems with these characters for some reasons. At least the problem persists even if I install a font like TNR which I know supports combining diacritics. I guess the problem would disappear after diacritics-to-number conversion is implemented. That might mitigate the problem with the @ as well. The other two problems appear to me like the don't have anything to do with the dictionary but with Pleco itself. Maybe mikelove knows more about it?
{
"vowels":
{
"a":
{
"á": "acute",
"à": "grave",
"â": "circumflex",
"ā": "macron",
"a̍": "vertical",
"a": "none"
},
"e":
{
},
"i":
{
},
"o":
{
},
"u":
{
}
},
"diacritics":
{
"acute": 2,
"grave": 3,
"circumflex": 5,
"macron": 7,
"vertical": 8,
"none":
[
{
"p": 4,
"t": 4,
"k": 4,
"h": 4
},
1
]
}
}Haha I guess that's a better learning method than classes anyways
This is actually a gross oversimplification as it only holds completely true for the "literary readings". However early Chinese dialectologists almost exclusively concerned themselves with the more "respectable" reading pronunciations, this view has spread far and even some scholars who should know better still repeat it. I guess a detailed discussion of that would be off-topic here, but we can open a new thread if you like
For our purpose here, suffice to say that the 6th tone disappeared in most variants of Minnan, including those recorded in the MoE dictionary.Looks correct to me. Depending on how you plan to implement it, you might have to check for whether a second "o" follows after the marked "o" because "oo" exists as a vowel distinct from "o". You will also definitely have to add checks for "m" and "n" with diacritics too, though, because Minnan has vocalic "m" and "ng" (in the latter case, the diacritic is put on the "n").Thanks - on first glance it doesn't look too difficult to automate the diacritics to numeric tone conversion.
EDIT: Can you check if this is an accurate representation of the mapping?
Code:{ "vowels": { "a": { "á": "acute", "à": "grave", "â": "circumflex", "ā": "macron", "a̍": "vertical", "a": "none" }, "e": { }, "i": { }, "o": { }, "u": { } }, "diacritics": { "acute": 2, "grave": 3, "circumflex": 5, "macron": 7, "vertical": 8, "none": [ { "p": 4, "t": 4, "k": 4, "h": 4 }, 1 ] } }
I've only done "a" so far but I think the other vowels should be the same?
Don't worry, I didn't have much time to test the second version and won't get much this weekend, either...
Ah right, I hadn't thought about that.
I played around with javascript a little and managed to write a script that can convert text from an input line in the way I imagine it to be. Probably is much messier than need be (I decided it's safer to declare a new variable every time something is edited, just in case, but that's probably not necessary) but at least it works
Code:<!Doctype html /> <html> <head> <title>Tâi-lô conversion script</title> <meta charset="utf-8" /> <script> function numfunc(inputForm) { // store input string in variable inp var inp = input.tlinput.value; /* Replace Space with "-q" and double hyphen with "-x" respectively. The "-" is detected when exploding in the next step, the letters are used to recognize the original spacing character and re-insert it later after re-implosion. A hyphen is also added in front of punctuation marks in order to seperate them from the preceding syllable ("." and "?" don't work)*/ var inputTrans = inp.replace(/ /g, "-q"); inputTrans = inputTrans.replace(/--/g, "-x"); inputTrans = inputTrans.replace(/,/g, "-,"); inputTrans = inputTrans.replace(/!/g, "-!"); inputTrans = inputTrans.replace(/\./g, "-."); inputTrans = inputTrans.replace(/\?/g, "-?"); // Split into Array var inpArray = inputTrans.split("-"); // Declare empty output array var outpArray = []; // For-loop goes through every element in inpArray (every syllable) for (i = 0; i < inpArray.length; i++) { /* If statements check existance of combining diacritic in string (acute = 2, gravis = 3, circumflex = 5, macron = 7, vertical line above = 8), delete it and place the corresponding number at the end of the string*/ if (inpArray[i].search("́") >= 0) { outpArray[i] = inpArray[i].replace("́", ""); outpArray[i] += "2"; } else if (inpArray[i].search("̀") >= 0) { outpArray[i] = inpArray[i].replace("̀", ""); outpArray[i] += "3"; } else if (inpArray[i].search("̂") >= 0) { outpArray[i] = inpArray[i].replace("̂", ""); outpArray[i] += "5"; } else if (inpArray[i].search("̄") >= 0) { outpArray[i] = inpArray[i].replace("̄", ""); outpArray[i] += "7"; } else if (inpArray[i].search("̍") >= 0) { outpArray[i] = inpArray[i].replace("̍", ""); outpArray[i] += "8"; } else { /* For all elements without diacritic marks, add 4 if they have a 入聲 coda, output them as is if they are punctuation and add 1 in all other cases */ if (inpArray[i].substring(inpArray[i].length - 1) == "p" || inpArray[i].substring(inpArray[i].length - 1) == "t" || inpArray[i].substring(inpArray[i].length - 1) == "k" || inpArray[i].substring(inpArray[i].length - 1) == "h" ) { outpArray[i] = inpArray[i] + "4"; } else if (inpArray[i] == "." || inpArray[i] == "," || inpArray[i] == "?" || inpArray[i] == "!" || inpArray[i] == "" || inpArray[i] == "q" || inpArray[i] == "x" ) { outpArray[i] = inpArray[i]; } else { outpArray[i] = inpArray[i] + "1"; } } } // Join output array to a string var output = outpArray.join("-"); /* Replace "-q" and "-x" with a spacebar and double hyphen respectively and delete the seperating hyphen in front of punctuation */ output = output.replace(/-q/g, " "); output = output.replace(/-x/g, "--"); output = output.replace(/-,/g, ","); output = output.replace(/-!/g, "!"); output = output.replace(/-\./g, "."); output = output.replace(/-\?/g, "?"); // Insert output in the "output" paragraph document.getElementById("output").innerHTML = output; } </script> </head> <body> <!-- Input form --> <form id="input" action="" onsubmit="numfunc()" method="get"> Input Romanization here:<br /> <input type="text" name="tlinput" /><br /> <input type="button" value="Click to output" onclick="numfunc(this.inputForm)" /> </form> <!-- Output --> <p>Output with numbers:</p> <p id="output"></p> </body> </html>
EDIT: Just thought of one problem: This script doesn't take punctuation into accout, so if a syllable is followed by a punctuation mark, numbers are added after it. (e.g. "
Tsa-bóo khiā tsit pîng, tsa-poo khiā hit pîng." --> Tsa-boo2 khia7 tsit ping,5 tsa-poo khia7 hit ping.5).
EDIT2: Streamlined it a bit in terms of number of different variables. Implemented numbering for 1st and 4th tone as well. Also taught it to recognize certain punctuation marks ("," and "!" to be precise) and add the numbers in front of them instead of behind. "." and "?" continue to be a problem because js syntax prevents me from using the same method as for "," and "!".
EDIT3: Now working for "." and "?" as well. I just forgot that I have to cancel those out with \
1: Khuànn-tio̍h tsit khuán lâng tō gê
Khuann3-tioh8 tsit4 khuan2 lang5 to7 ge5
2: Kè-á tu khah kuè--khì--leh.
Ke3-a2 tu1 khah4 kue3--khi3--leh4.
3: Kā phue̍h tsānn--khí-lâi.
Ka7 phueh8 tsann7--khi2-lai5.
4: Hit nn̄g uân oo-oo ê mi̍h-kiānn sī siánn-mih?
Hit4 nng7 uan5 oo1-oo1 e5 mih8-kiann7 si7 siann2-mih4?
5: Honnh, guân-lâi sī án-ne--ooh!
Honnh4, guan5-lai5 si7 an2-ne1--ooh4!
6: Tsa-bóo khiā tsit pîng, tsa-poo khiā hit pîng.
Tsa1-boo2 khia7 tsit4 ping5, tsa1-poo1 khia7 hit4 ping5.Looks correct to me
Looks correct to me
I also tested the second version some more. The problems you have addressed (the ones with the "example" and "type" fields) were successfully fixed as far as I can see and I didn't find any new ones either (well, I did find a spelling mistake in one entry, but that's a problem of the source, not the conversion).
I was also able to pinpoint the behaviour of @ in searches: Adding @ returns all entries that contain the string which follows after @ but don't begin with it. So searching for "@in" returns "lin", "thinn", "iau-kin", "so-inn" ect., but not "in", "inn" and so on. The syllable-seperating dash is not taken into account for some reason, so "pai-ni" is returned as well. I don't know whether this is something that can be fixed, though
Importing atm. Are there any special conditions in particular which you suspect might cause bugs and which I should look out for?
Pretty much, I guess^^ I can only think about two things which we might think about including, but none of them is absolutely essential if you ask me.If this works then I think we're pretty much done?
@audreyt's 萌典 doesn't display it, either.
Cases where there is a lot of switching between Chinese and Latin characters without separating vocab might trip up the logic - I think I have got enough recursion in the logic to catch all likely cases, but some might have slipped through the net.
Multiple files don't really make a big difference here - might take a bit longer to run the script unless I set up a temporary relational database, but nothing conceptually difficult about it.
That would be quite easy to do, I can add it to the next version and see if it's better with or without it (or if it might be better somewhere else, like at the end of the definition).The information in the "reading" field of the main json could be included as well, but I think they would have to be recognizable as what they are at the very first glance so they don't create confusion. The MoE website does this by displaying them inside a square behind the header character which I don't think is possible in Pleco because it doesn't seem there are any special (squared, circled or whatever) forms of these characters in Unicode (the MoE used image files). Maybe putting it at the top of the entry full space angled brackets (【】) would be visually clear enough... But in my opinion it's not an absolute must anyways
If you're doing it manually then anything close to Pleco flashcard format would be best (have a look at the MoE-Minnan ones for an example):
You mean a lot of changing between Characters and Latin letters within a single entry? The most extreme examples are probably single character entries which have a lot of meanings. I checked a few and couldn't see anything out of the ordinary
However it did give me the idea that the translation of examples could be put in parentheses to make it look neater xDI could do that, but I doubt that's particularly practical. Wouldn't it be a bit like a website which is styled in html instead of using a spreadsheet, i.e. written with only the immediate output in mind? It would be rather inflexible in terms of possible changes to layout because every line would have to be checked by hand, wouldn't it?
Yeah, switching between Characters and Latin without punctuation between them.You mean a lot of changing between Characters and Latin letters within a single entry? The most extreme examples are probably single character entries which have a lot of meanings. I checked a few and couldn't see anything out of the ordinary
An Excel sheet is fine, as you can easily output that to CSV or tab-deliminated format (pretty much Pleco flashcards) anyway, both of which can then be read into a script or database.
Yeah, that should occur most often in single character entries with a lot of meanings because usually each meaning would have at least one example and with single characters (i.e. not full words), the examples would not be full sentences. I didn't find any problems so far, though
Uploaded an excel sheet with the family names, loan words and 24節氣 (https://www.dropbox.com/s/415y5jd5jt4cg3d/MoE_Dict_appendix.xlsx?dl=0). I'm working on the toponyms but as I said, there are more of those than I thought. Moreover, I will be very busy during this weekend and the coming week and probably won't get a lot done there (if anything), so it might take a bit.
My priority would be: Appendix > 異體字 > "reading" > parentheses around example tranlations.Let me know what you think the priority items should be for the next version.