Open bhajneet opened 4 years ago
Required by #395
For now it will be a toggle so the "icon" can say ENG/ROM (english / roman) and change to ਪੰ/ਗੁ (punjabi / gurmukhi). If it says the former the chars will remain in english, if its the latter then ascii will convert to unicode gurmukhi.
In the future it can rotate through or context menu for whatever languages scripts we are supporting -- nastaliq (urdu), hiragana (japanese), etc.
Maybe its better to keep it short and say EN
or ਗੁਰ
?
Gur is something that could be searched, so I thought it might be confusing to users. But as long as it's clearly a separate button from the search query input, I think it's okay. Also I would try to go for alphabets. So since gur is for gurmukhi, we should maybe do RO for roman or LA for latin? Because it can be used in the future to search spanish translations as well.
Edit: We can follow Unicode script names, that seems pretty standard. So it would be abbreviations of Latin, Gurmukhi, Devanagri, and Arabic. This would cover gurbani, punjabi, english, spanish, urdu, etc. that we have so far.
Script | Proposal |
---|---|
Latin | L |
Gurmukhi | ਗੁ |
Devanagri | ना (from देवनागरी) |
Arabic | ?? (from عَرَبِيّ) |
I'm actually leaning towards the single letter because the user should just be able to tell what they're typing in, simply by looking at the script. An L or ਗੁ gives that away pretty easily imo. The context menu or rotation or hover-indicator can express the full script name.
I would say that EN is pretty standard in terms of what people recognise. I'm not sure I'd know what L actually meant without that table
I would say it's more about recognizing the character script than knowing what the letter stands for.
E can work for English and Espanol, but German, French, etc. will be confused by EN perhaps. My thoughts are instead of being a single-letter (E) to recognize the script, the combo of EN may imply that interpretive search will fail to look for spanish, german, french, etc. translations / transliterations.
Perhaps the first letter of the alphabet can work in all cases. AFAIK, all major Latin languages begin with A (same with arabic and devanagri, though not gurmukhi). Admittedly, Arabic looks a bit simple using the finalized form of their first letter. Then you'd have:
Script | Orig Prop | 1st letter | "A" sound |
---|---|---|---|
Latin | La | A | A |
Gurmukhi | ਗੁ | ੳ | ਅ |
Devanagri | ना | अ | अ |
Arabic | ع | أ / ـا | أ / ـا |
Personally, I'm actually a fan of the original proposal, because they are easy to differentiate and non-specific to a language. The arabic character proposed can be found in both persian and urdu alphabets. Whereas the alif, used in the 1st letter and "a" sound columns, is slightly different in urdu.
This is more important after we've implemented better interpretive search for multiple Latin languages. If we pick one standard now, it will avoid confusion in the future. I don't think it will be too confusing to see an L to signify lack of conversion to gurmukhi.
As an aside, if we implement something like hindi or arabic, are there standardized keyboards that will map to their unicode chars? Will this be difficult/repeated-effort? Perhaps we don't want to implement those two languages and focus only on latin and gurmukhi conversions and rely on user's unicode keyboards for other languages.
Going with A and ਅ since they are direct translations. Typing capital a in ascii to gurmukhi converts to ਅ
I would like to toggle/rotate through these options using the ctrl+/
hotkey after the user is already on search. Could be normal hotkey or long-press hotkey to do so, but a quick keyboard only method of switching/rotating input mode would be excellent.
How's this?
_Originally posted by @bhajneet in https://github.com/ShabadOS/desktop/issues/393
Users on mobile can actually use the gurmukhi unicode keyboard.
Related to universal search + filters methodology.