[Unofficial] Feature Request / Suggestion List

[Shun]

Hi jiyan and jurgen85,

FWIW, here is a similar question I had put five years ago:

Filter sentences in SENTS tab

Hi, since the list of sentences in the Dictionary SENTS tab can get very long, could one add a search field at the top of the list of sentences, using which the Chinese sentences and their translations could be filtered for a Chinese word or a word in another language? As far as I know, there...

plecoforums.com

Cheers,

Shun

 

[jurgen85]

Merge flashcards with “identical” definitions

Thanks - this has already been fixed for 4.0 (cards can now link to multiple entries together).

Great! Will it be manual or automatic though?

1. I'm a bit worried about backwards compatibility. I probably have quite a few "incomplete" flashcards that I would like to link to all definitions without having to sift through all thousands of them
2. I just did a flash test with Remap cards to dicts. When the card for 聊 came, it picked OCC's first definition:

   ADVERB, LITERARY
   1 暂且 tentatively
   2 稍微 slightly

   which is quite different from the

   VERB, INFORMAL
   chat

   that we all know and love. Could Remap cards to dicts also be made automatic to include all those definitions? (there's a def for "rely on" too... Humans are not meant to keep track of all those imo.)

 

[jiyan]

If I may add to this:

1. In normal dictionary search, it would also make sense to be able to search for multiple full-text strings like #虽然#但是, and also filter matches you don't want, perhaps an exclamation mark like #可!#可是 in analogy with !=

2. Being able to search specifically in either examples or defintions-excluding-examples, i.e. not both at the same time. Searching for examples would have a different list layout (like the one in the Sents tab) focused on the examples themselves rather than where they are found.

Yes, that makes sense.

Hi jiyan and jurgen85,

FWIW, here is a similar question I had put five years ago:

Filter sentences in SENTS tab

Hi, since the list of sentences in the Dictionary SENTS tab can get very long, could one add a search field at the top of the list of sentences, using which the Chinese sentences and their translations could be filtered for a Chinese word or a word in another language? As far as I know, there...

plecoforums.com

Cheers,

Shun

Hello Shun,

I am not surprised it's not only me that felt a need for this. That's why I was a bit unsure and thought I might have missed something.

I understand Mike's reasoning about cluttering but I think too that this is an important function that can be expanded later on. I am sure that a smart solution can be found. Might also be an opportunity for addons with high quality example sentences, apart from those that already come with the dictionaries, that has an edge over just searching over the internet.

 

[Shun]

Hi jiyan,

no problem at all. I like your idea about add-ons with more example sentences. Luckily, this is already possible in a way now, with Pleco 3.2, by putting the sentences in a custom user dictionary (as I have done here). In Pleco 4.0, we can access flashcard categories as we would dictionaries, according to earlier posts from Mike. 反正, Pleco 4.0 seems to be designed with a very open architecture, judging from what I've read from Mike, which should allow users to harness Pleco in very smart ways on their own.

I also feel that the problem of clutter shouldn't be a very big one. It's just that Mike is probably putting most of his available time into the development of Pleco 4.0, and limiting updates to 3.2 to absolutely necessary changes demanded by the OSes.

Fortunately, while Pleco 4.0 is under development, I can still work on my Chinese ability quite unimpeded. I still consider my progress in Chinese the most important thing, with the arrival of Pleco 4.0 a close second.

Cheers, Shun

 

[mikelove]

Would be great if those words of the day (or even morning/afternoon/evening) could be taken from a person's own specific flashcards.

If we did that it would definitely make sense to customize it, yes.

If I am interested in looking up names, I usually do either a fulltext search, or search for the hanzi directly. It's not uncommon to see 2 or 3 of the top list items wasted on surnames or country abbreviations, out of 8 visible on my 5 inch phone (with the keyboard open). On top of this some dictionaries use all lowercase for names anyway which adds to the mess.

Should definitely be optional, yes.

So unless there is already a way and it's me that hadn't noticed yet, it would be nice to have a search function on while browsing example sentences.

We're not planning to add a search box to the definition screen but we do now support direct search of example sentences from the main screen in 4.0 so you should be able to rig up something like this then.

1. In normal dictionary search, it would also make sense to be able to search for multiple full-text strings like #虽然#但是, and also filter matches you don't want, perhaps an exclamation mark like #可!#可是 in analogy with !=

Already supported for 4.0, yes, though the negating is still a little buggy and I can't promise it'll be supported initially.

Great! Will it be manual or automatic though?

It won't automatically upgrade old cards to include all linked entries, but the remap function will indeed populate all of them.

I understand Mike's reasoning about cluttering but I think too that this is an important function that can be expanded later on.

That was more of a retrospective kind of reasoning, to be honest - at this point I'm (maybe naively) feeling like we're close enough that it really would be a waste to put more work into adding features to 3.x, so I don't think we're likely to add anything this ambitious to it now.

But I wish that, say, 5 years ago, after we'd finished up 3.0 on iOS/Android, we'd started churning out a steady series of annual 3.x updates adding the half dozen or so most popular not-impossible-in-our-existing-app feature requests each year and then quietly working on 4.0 between those updates - 4.0 might have taken a year or two longer that way, but I don't think people would have minded that much if they were getting a lot of their needs met in the meantime.

 

[icebear]

It would be great if the reader was capable of:

1. Making small edits to files opened locally. I sync a folder of Markdown format articles between my computer and phone; I'd like to be able to open these directly in Pleco and add or deleting #tags, asterisks for bold and italics, etc. Not serious word processing, just minor edits.
2. Pleco reading those Markdown (.md) files correctly with bold, italics, headings etc. No need to hide the symbols, just modify the style around them so I see the visual formatting cues that help.

 

[mikelove]

We already support local text editing on iOS, will probably bring it to Android for the sake of consistency at some point.

We actually use an expanded version of Markdown for custom card / entry editing in 4.0, so while we hadn’t explicitly done that in order to add Markdown document support we probably will support it too.

 

[LovePlecoSoMuch]

Thumbs up for the idea with multiple tests. Or is there any other way to start a test where you are going through all your learned vocabulary and another test where you just learn new stuff. The first one i can not finish at one day and the second one would be repeated every day

 

[mikelove]

You can’t have them running simultaneously at the moment, but if your multi-day test included a filter that excluded cards last reviewed since whatever date you started running through them, that would let you exit it and resume it the next day carrying on where you left off.

 

[jurgen85]

Vertical variants

Variants mixed with the "normal" characters get quite confusing if there are more than one or two, which could be mitigated by another layout. See attached mockup:

(btw, why are KEY's variants shown as separate items rather than merged into variants here?)

 

[mikelove]

Interesting idea, thanks. My biggest concerns are the amount of whitespace and the fact that it gives the impression that a particular row of variants are linked together when in many cases they aren't; the current plan is to handle this by simply listing variants below the headword.

KEY: not sure, will check on whether some variants ought to be merged that haven't been.

 

[jurgen85]

As for the whitespace, yes, though in most cases it would only take (even a little less than) a row more. (For my example's sake, I included more variants (谷 古 冬) than are displayed normally, hence the KEY question. Without those added variants it would actually save space!)

The impression of variants being linked to each other might be counteracted by parentheses or separator lines? (see new attachments)

Happy to hear you are planning to handle it one way or another!

EDIT: for bonus confusion, see pilipala/噼里啪啦

 

[mikelove]

Those do help, but they also risk pushing us further into 'visual clutter' land a bit when we already get a lot of complaints about that. (of course the current approach presents some clutter too...)

 

[Weyland]

Those do help, but they also risk pushing us further into 'visual clutter' land a bit when we already get a lot of complaints about that. (of course the current approach presents some clutter too...)

If that's the issue; Why not just make it toggleable like Cantonese pronunciation is?

 

[jurgen85]

Punctuation and fonts in C–C dicts + headwords + examples

“More and more people are saying it:”

I've been using the Gu Hanyu Da Cidian for a while and I think definitions would be easier to read if it used Chinese punctuation (。，：) including 「」quotation marks, instead of Western punctuation (.,:""...). Other Chinese to Chinese dictionaries in Pleco such as MOE and LAC already use full-width punctuation marks. Is that something that could be fixed?

I've noticed a lot of punctuation in Pleco is halfwidth and not full-width like most Chinese style standards demand, for instance:
- ｢､｣ vs. ｢、｣
- ｢;｣ vs. ｢；｣
- ｢｡｣ vs. ｢。｣
- ｢,｣ vs. ｢，｣

However, I find the major offender to be GF and occasionally LAC. I don't know if I've ever seen full-width commas [，] or colons [：] [；] used in GF (obvious with a centered punctuation font), and it sometimes uses the strange above mentioned half-width ideographic punctuation like [｡] [､] too (sometimes followed by a space, sometimes not).

But it's not only about the correct code points but also the font: the standard quotes in simplified [“] [”] share code points with the Latin ones, and are therefore shown in the Latin font, which doesn't render them in full-width. Digits also share code points, and are usually proportional in Latin, but look better as half-width in Chinese. Parentheses as well, ellipses … and probably some more I forgot. This also compounds with the "Enlarge Chinese characters" setting for some rather unsightly results.

All this goes for headwords and examples as well! I suggest both to replace all of the punctuation here with full-width, and to render it as Chinese by default, and perhaps to only switch to Latin if there are more than a few Latin alphabetic characters in a row.

 

[mikelove]

This is intentional - something we settled on with our type designer when making 3.0 - but it's certainly debatable. You can apply arbitrary text processing transforms to definitions in 4.0, including a half->fullwidth converter, so if you prefer that it all be fullwidth that should be something you can get then.

 

[jurgen85]

That sounds great! What will it mean for digits though? (since they have the same code points in both languages.) And will it also be available for headwords and examples?

 

[mikelove]

Would be for everything, yes.

Digits: we'd actually already been planning to switch to fullwidth digits in Chinese anyway because we're switching to oldstyle numerals by default for body text; they look fantastic with English but extremely silly with Chinese.

However, if we somehow don't make that switch you could easily put together a text processor chain that would pick out numbers adjacent to Chinese text via a regex and apply a half->fullwidth transformation only to those.

We have also been considering switching to fullwidth for everything in Chinese and then reversing that transformation with a default processor, since then you could simply disable that to get the correct width for each set.

 

[jurgen85]

Not to entangle this thread all too much in me nitpicking orthography, but are you sure you mean fullwidth digits? I've understood the standard to be either (monospace) halfwidth or proportional digits, which can only be changed at the font level since unicode does not differentiate those two.

 

[mikelove]

The thinking was to go completely fullwidth, but you raise an interesting point. It would not be too difficult to apply a font variant for tabular lining numerals in Chinese text and proportional old style in non-Chinese text, just have to figure out a way to keep the relevant settings from getting too ridiculous.