Flashcard import: force use of import file pinyin pronunciation

etm001

状元
Hi,

Scenario: a flashcard file contains only a) Chinese words, and b) pinyin pronunciations. There are no definitions. Pleco import is configured to use dictionaries for definition sources.

Desired Functionality: Pleco uses dictionaries for definition sources, but uses the import file's pinyin pronunciations, not the dictionary pronunciations.

Current Functionality: Pleco uses the dictionary pronunciations, not the import file's pinyin pronunciations.

Explanation: recently I had two instances where I wanted Pleco to work in the manner described above:
  • The official word lists for Taiwan's TOCFL (aka TOP) do not contain definitions, just the Chinese characters and pinyin pronunciations.
  • A textbook I'm using contains only Chinese explanations (I hesitate to call them definitions) for vocabulary words. I want to study flashcards with English definitions.
I both of the above cases the import file would look like this:
企業 qi4ye4
皮夾 pi2jia2
...​

I want Pleco to observe the import file pronunciations because they may vary from those in the dictionaries. For example, the pinyin pronunciations above are standard in Taiwan, but would be 'qi3ye4' and 'pi2jia1' in other places.

Of course, you can convert an imported, dictionary mapped flashcard to a custom card, then change the pronunciation. This is feasible when the number of flashcards is small, but with large lists it becomes increasingly impractical.

Thanks!
 

mikelove

皇帝
Staff member
We do it this way because of 多音字 - there's no guarantee that the Pinyin you supply would actually match the definition we pick for you.

One slightly awkward workaround would be to import the list *with duplicates allowed* (so the # of cards you import will exactly match the # in the file), export it again as a text file, open that file in Excel, paste the Pinyin column from your original list over the Pinyin column in our exported file, undo / delete the cards you just imported and then import again from that updated file.
 

etm001

状元
Thanks Mike.

One other helpful item that I forgot to note: if you have a region-specific dictionary in Pleco that has your preferred pronunciations (I have the user-defined Taiwan MOE dictionary), then you can place it at the top of the list when configuring the import, and you'll end up with the pronunciations you want. But this is not foolproof because the dictionary might not have a given word, in which case you will end up with an entry (and possibly a differing pronunciation) from another dictionary. (In my specific case this also doesn't work because I want English definitions, and MOE is Chinese-Chinese). So in the end, the work-around you described is the safest bet.
 

gato

状元
What about making it a custom card under "Organizing cards"? Can't you change the pinyin that way?
 

etm001

状元
What about making it a custom card under "Organizing cards"? Can't you change the pinyin that way?

Yes, you are correct. I mentioned this in my first post:

Of course, you can convert an imported, dictionary mapped flashcard to a custom card, then change the pronunciation. This is feasible when the number of flashcards is small, but with large lists it becomes increasingly impractical.
 

gato

状元
Are there that many words with different pronunciation between Taiwan and mainland?

I guess the issue is the time that's required to check?
 
Last edited:

etm001

状元
Plenty of words have different pronunciations. Most are probably just differences in tone, but some are also phonemic. (Sorry, I'm not a linguist but I think that's the right term).
  • Tone difference: 企業, qi4ye4 in Taiwan, qi3ye4 on the mainland
  • Phonemic difference: 角色, jiao3se4 in Taiwan, jue2se4 on the mainland
The differences are not set in stone - I've come across both pronunciations for 角色 in Taiwan, for example. In the end, the differences are not such that someone who learned Mandarin in Taiwan can't be understood on the mainland, and vice versa.

And yes, time necessary to check a large flashcard list is prohibitive, but Mike's suggested work-around solves the problem.
 
Top