While working on AnkiDroid localization, I thought that it would be great if instead of “deck:foo” the users could use whatever word “deck” is in their language. But as we follow upstream and share the same set of preferred search, we can’t do it unless you accept it. Would you ? I do realize that there is two problems to solve:
- we need to ensure that in each language we have the same translation. Hardly impossible to do until we actually share back-end strings
- a saved search, or even a copy-pasted one, will break if a user have a search string in non-english language A and use it in a non-english language B (I expect that “deck:” will still be valid even in language where it means different things)
There is also a risk of ambiguity if “deck” in a foreign language means something such as “card”, but i doubt it’s worth considering this theoretical risk
I tried to create it myself, but honestly, my rust level is clearly not high enough to figure out how to use tr: I18n without changing the entire search codebase and putting everything into the Collection structure (and I’m not even sure it would be sufficient)
I don’t like this idea. There are 129 dialects in China, and they may not have the same Chinese words for same thing. Shall we define different keyword for different dialects ?
e.g. In Chinese, deck can be 牌组 or 牌堆 or 牌套 or 牌库 or something I don’t know (I am not a poker player). Which one will you go with?
I don’t understand why you mention poker.
Deck is a term used in Anki. It represents a collection of cards. In each localization of Anki, a word is used to represents this collection of cards. I have no idea how Chinese translators deal with it, but if there is a Chinese localization, they had to deal with it one way or another. The search bar would simply use the same word as the one used today in anki.
I definitely prefer typing in the English keywords instead of lengthy German translations. But I assume the current hardcoded keywords would remain valid regardless of the localisation?
My main point of concern is the volatility of the translations. The search syntax would change every time a translation is updated and the search will break if the keyword contains a space (or a couple of other, probably less likely to appear characters). Also, if the syntax isn’t hardcoded, it won’t be possible to document it reliably (and most localisations don’t have a manual anyway) so where would users find out about the localised keywords?
I’m sorry Arthur, I don’t think that is practical. Aside from making the parser more complicated, deck authors would not be able to use any fields that may happen to be used in any of the translations out there as a keyword. There’s a reason why programming languages don’t translate their keywords.