search

filipst / hackerskeyboard

Automatically exported from code.google.com/p/hackerskeyboard
0 stars 0 forks source link

Turkish layout #108

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Set Turkish as input language
2. Use Hacker's Keyboard

What is the expected behavior? What do you see instead?
I see generic English layout, not Turkish.

What version of Hacker's Keyboard are you using? (See top of the app's
Settings menu.) On what phone or tablet?
Version 1.27, Motorola ATRIX 4G

If applicable, does this affect the 4-row or 5-row layout, or both? Which 
language(s)?
Both, Turkish.

Please provide any additional information below.
None of the keyboard apps I've seen has the Turkish layout, only some has the 
Turkish-specific letters with long-press menu. (Like dotted capital i and 
dotless i.)

http://en.wikipedia.org/wiki/File:KB_Turkey.svg
Here is the original Turkish layout in QWERTY style but slightly different. It 
might be hard to fit it in 4-row layout, but on 5-row, it could be done. It is 
hard to type when some of the letters you use often are only accessible by 
long-pressing.

Note: There'a also another layout starting with the letter F, you can check it 
too on corresponding Wikipedia article. I don't need it but obviously, there 
are people who would.

Original issue reported on code.google.com by photo...@gmail.com on 16 Nov 2011 at 2:54

GoogleCodeExporter commented 9 years ago 
I'm looking into it, now that I finally have capitalization fixed so that it 
can correctly handle ı->I and i->İ.

As you say a 5-row layout should not be a problem, but the 4-row one would need 
6 more letters. A 11x4 layout can fit 4 more keys, or 5 if shrinking shift and 
backspace to normal key size, which isn't quite enough for them all - are any 
of them sufficiently rare that it would be ok to leave them off the main map? 
Adding more keys than that may be a bit cramped.

Alternatively, I could add dead accent keys for the ¨ and ¸ marks which would 
save two keys, so that typing "¸" and "c" would produce "ç". Not as 
convenient as dedicated keys, but would it be better than a long-press?

Yet another option - according to Wikipedia the letters Q,W,X aren't used for 
Turkish, but I guess leaving them off the keyboard would result in a rather 
nonstandard layout.

What do you think would work best?

Original comment by Klaus.We...@gmail.com on 31 Dec 2011 at 4:58

GoogleCodeExporter commented 9 years ago 
First of all, thanks for handling it.

I guess the cleanest choice would be leaving the 4-row view unchanged. Keys are 
already too small to use and there's not much space for those letters. People 
can use 4-row for general use with long-press keys and  5-row for a more 
comfortable typing experience -as intended.

Dead accent keys are never used in Turkish, it would be uncomfortable for most 
people. Q, W and X keys are not used in Turkish, but there are a lot of import 
words and removing them would change the usual layout like you said. Out of 
option.

In short, 4-row would be better off unchanged and 5-row as the Wikipedia image.

Lastly, there are a couple of details I would like you to fix.

- In the 4-row layout, when lowercase, default letter should be "i" (dotted) 
and when uppercase, default should be "I" (dotless) and their alternatives in 
the long press menu. (Just like English layout.) That would feel more natural.

- In addition to the Wikipedia image, the comma key (, ; `) would be better if 
it was places below Ü (dotted U) key, next to Enter. Many keyboard 
manifacturers use it as standard, and key placement would be better. (For 
5-row.)

You can ask me anything about it, I'll be happy to help, since there are no 
other soft keyboard developers interested in making Turkish layout better.

Thanks.

Original comment by photo...@gmail.com on 3 Jan 2012 at 8:50

GoogleCodeExporter commented 9 years ago 
I'll look into it, thanks for the explanations. I agree that keeping the 
current 4-row layout sounds easiest.

For the 4-row layout, using the i/I mapping may cause inconsistencies with 
prediction. If the user is trying to type a word that starts with dotted "i" 
and the keyboard is in caps mode, typing dotless I at the start of the word 
would trigger a search for suggestions starting with dotless "ı" and then 
uppercase them. (I don't know Turkish, are there such words?)

So you'd get a completely different set of suggestions depending on if you 
start typing in caps or normal mode, instead of case variations of the same 
words, which sounds confusing.

Original comment by Klaus.We...@gmail.com on 3 Jan 2012 at 10:24

GoogleCodeExporter commented 9 years ago 
I haven't thought of suggestions, I never use them. I just thought since 4-row 
one looks just like English layout, it would look weird with capital dotted i. 
(I'm also checking Cyanogenmod keyboard and it also does that. Totally weird 
when it's uppercased.)

I think it's going to look confusing whatever way you choose. It's impossible 
to fit both of them, and since they're vowels they're used pretty much in any 
sentence. It's up to you, but there's no clean way to do this. (I prefer 
unchanged English layout.)

Original comment by photo...@gmail.com on 3 Jan 2012 at 10:47

GoogleCodeExporter commented 9 years ago 
I've added a 5-row Turkish layout, try v1.28rc16 (or later) from 
http://code.google.com/p/hackerskeyboard/downloads/list and let me know how 
this works for you. I've added some extra long-press alternates based on the 
Turkish system keymap on my Ubuntu system.

The accented é on the top-left key is a bit oddly placed. If it were in the 
main position and not in the shifted position, it would get uppercased when the 
keyboard is in AutoCaps or CapsLock mode, see for example the French AZERTY 
keyboard. But if it's rarely used, this shouldn't be a big issue. How do you 
get an uppercased version of that on a physical keyboard?

Unfortunately I can't easily move the comma key as you suggest, that would make 
the Return key very small. The hardware keyboards that do that have a 
double-height Return key, and the current keymap system doesn't support that.

For the 4-row mode, would it make more sense to use dotless ıI for consistency 
with the corresponding locations in the 5-row map?

Original comment by Klaus.We...@gmail.com on 4 Jan 2012 at 2:58

GoogleCodeExporter commented 9 years ago 
I checked it out, 5-row view is just perfect. Windows and Ubuntu keymaps are a 
little different. Other than minor differences related to alt characters; in 
Windows, you type letters with circumflex (like â, î or û) after you press 
Shift+3 (^ character, it's not shown until you press another key). But in 
Ubuntu, (or X keymap generally) they are typed as alt keys of corresponding 
letters. (AltGr for lowercase, Shift+AltGr for uppercase.) I like the Ubuntu 
way, but you may consider the other one?

Accented e (é) is rarely used in Turkish, no need to put it in shift mode. And 
comma placements is no big problem, it's still usable this way. I tried and I'm 
happy with the results.

There are a couple of things I want to say about 4-row view:

- When people are typing in Turkish, if there are no Turkish special letters, 
they tend to type using alternative ASCII keys. (i for ı, c for ç, o for ö 
and so on...) Especially when texting, since using Turkish only letters change 
the SMS mode and you got only 70 characters instead of 140. Thus, leaving 
English layout for 4-row would be best, IMHO.
- In 4-row layout, commonly used letters (ö, ç, ğ, ş, ü...) should be 
closer to the finger position. And you can remove the unneeded letters from 
popup menu too. (I never use those letters: ₣đàžñ) When I got spare time, 
I can list commonly used characters for you. But having common letters easier 
to access must be a higher priority.

That's all I got for now. Thanks for everything again!

Original comment by photo...@gmail.com on 4 Jan 2012 at 10:15

GoogleCodeExporter commented 9 years ago 
I just uploaded 1.28rc18 to 
http://code.google.com/p/hackerskeyboard/downloads/list with tweaks to the 
Turkish layout. The 4-row layout now has plain ASCII iI with the other 
variations available by long-press. I've moved the alt characters around a bit 
to make them easier to trigger, let me know if others should be rearranged too.

Bonus feature: try a swipe-up gesture to activate an extension row with extra 
letters in 4-row mode. What do you think?

The dead circumflex is available by long-pressing the "3" key.

Original comment by Klaus.We...@gmail.com on 6 Jan 2012 at 7:41

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I tested it and got some FCs. Long pressing "." or "/" key always ends up with 
an FC. (Motorola Atrix, CM7 Ba2tF) I also got an FC the other day but I can't 
remember how I triggered it. Probably in the alternative characters view.

There are a couple more things to do with 4-row layout, mostly polishing. 5-row 
has the dead circumflex, but it's still hard to get the letters with circumflex 
(â, û, î) in 4-row layout. You can move them around too. And I'm pretty sure 
it's safe to remove alt keys for f, d, z and n. They're never used and it's a 
little distracting when all hint labels are shown. (I turned it on due to 
troubleshooting reasons.)

That's all for now.

Original comment by photo...@gmail.com on 7 Jan 2012 at 10:10

GoogleCodeExporter commented 9 years ago 
I fixed several FCs triggered by the popup refactoring. The code was assuming 
that having popups or not is a per-key property, and this now varies depending 
on the shift/caps state and popup content settings which confused it.

I just uploaded rc20 a bit ago. Let me know if you still get crashes in that 
version.

That version doesn't include the alt char changes yet, here's the current 
edited version I'm planning for the next one:

    <string name="alternates_for_a">âàáãäåæ</string>
    <string name="alternates_for_c">ç</string>
    <string name="alternates_for_d"></string>
    <string name="alternates_for_e">3êèéë</string>
    <string name="alternates_for_f"></string>
    <string name="alternates_for_g">ğ</string>
    <string name="alternates_for_i">8ıiîïíì</string>
    <string name="alternates_for_n"></string>
    <string name="alternates_for_o">9öôøœõóò</string>
    <string name="alternates_for_s">ş§ß</string>
    <string name="alternates_for_u">7üûúù</string>
    <string name="alternates_for_y">6ÿý</string>
    <string name="alternates_for_z"></string>

Let me know if anything else should be removed or reordered, you can just paste 
an edited version in this bug.

Original comment by Klaus.We...@gmail.com on 8 Jan 2012 at 1:52

GoogleCodeExporter commented 9 years ago 
Forgot to add, it inherits values from this file: 
http://code.google.com/p/hackerskeyboard/source/browse/java/res/values/donottran
slate-altchars.xml

If the parent file defines alternates you don't want, add a corresponding line 
in the "tr" version with a blank definition to remove them, as I did for 
"alternates_for_z" above.

Original comment by Klaus.We...@gmail.com on 8 Jan 2012 at 1:55

GoogleCodeExporter commented 9 years ago 
No more crashes, thanks. I found no other problems but the alt key changes, 
which you stated you'll add in the new version.

Alt key map is perfect this way, but will it apply to the uppercase letters 
too? I mean rc20 has a problem with it, the first letter to come up in the 
popup windows for letter "i" is capital "I". (It might be because of default 
popup setting, let me look at it.)

Thanks again, waiting for the next update.

Original comment by photo...@gmail.com on 8 Jan 2012 at 2:21

GoogleCodeExporter commented 9 years ago 
Yes, I figured it out. When I changed the "popup mini-keyboard content" option 
to "unique only", it kinda fixed. But when I'm typing the first letter of a 
text-area (which is most of the time capitalized) I can't access the "İ" 
letter using the popup menu. Maybe it's not the same as the shift-pressed 
position?

One more small bug. When I long-press a button for the first time after I open 
the keyboard, right before the popup menu shows, I see the ordinary popup, but 
it's empty and narrow. Somehow I don't see it later. I thought I imagined it 
the first time I saw it, but at the second time I was sure. Weird, huh?

Original comment by photo...@gmail.com on 8 Jan 2012 at 2:31

GoogleCodeExporter commented 9 years ago 
Try rc21, I've updated the altchars and tweaked the popup logic in revision 
18fa08e3d9c2 . In short, it wasn't uppercasing the alternates in autocaps/caps 
lock mode even though it should have.

Now the 4-row mode iI key should consistently have dotless ı as an alternate 
in normal (unshifted) state, and dotted İ in shifted or autocaps/caps lock, 
even in "unique only" popup mode. The other popup modes add additional 
characters.

I've also fixed the mis-scaled feedback popup, see revision a8b3ac0e3b96 if 
you're curious what went wrong.

Original comment by Klaus.We...@gmail.com on 8 Jan 2012 at 7:24

GoogleCodeExporter commented 9 years ago 
The popup is no longer misscaled and also "Ii" popup is fixed now, but works 
best if the "unique" option is set. (By the way, it works but it's not the same 
as what's seen on the hint label. Both for uppercase and lowercase "i", hint is 
capital "I". Weird.)

I changed 3 letters' alt keys a little. Since "@" is accessible on the Q key on 
the full keyboard, I added it as alt key. And removed "ô" and "ê" keys, 
they're not used in Turkish. A common misunderstanding. Here's only the changed 
ones:

    <string name="alternates_for_e">3éèë</string>
    <string name="alternates_for_o">9öøœõóò</string>
    <string name="alternates_for_q">1@</string>

And I have two questions that's been bugging me. When I press the Alt key on 
5-row layout, I can't see what'll come out until I press a key. Is this a bug? 
And the smilies in the messaging app, are they stored in the messaging app or 
the keyboard? (I hate the hyphen in the smilies...)

Original comment by photo...@gmail.com on 8 Jan 2012 at 4:06

GoogleCodeExporter commented 9 years ago 
I've integrated your suggested change for the alt chars, see revision 
5a90beaf8aa3, it'll be in the next prerelease.

In the 5-row layout, the Alt key currently just acts as a modifier, and doesn't 
have much effect in most Android apps other than ConnectBot or remote desktops. 
I'm planning to add support to have it act as an AltGr key which sends 
alternate characters, but that's not yet implemented.

The smilies are configured in the keyboard, hardcoded in this file: 
http://code.google.com/p/hackerskeyboard/source/browse/java/res/xml/popup_smiley
s.xml

As part of the planned keymap customization, this should be configurable, but 
before then I'm afraid you'll have to live with the current set, sorry.

Original comment by Klaus.We...@gmail.com on 9 Jan 2012 at 3:53

GoogleCodeExporter commented 9 years ago 
Looks like there are no more problems with Turkish layout, it'll be a pleasure 
to type in Turkish using Hacker's Keyboard. (At least Q layout. But since I'm 
not experienced in the F layout, I can't be much help here with it.)

Looking forward to the configurable keymap feature, so I can get rid of those 
hyphens out of my smilies.

Thanks for your help!

Original comment by photo...@gmail.com on 9 Jan 2012 at 11:41

GoogleCodeExporter commented 9 years ago 
[Bulk bug update] The new Market release 1.29 includes the changes from the 
v1.28 prerelease series, and these "FixInTest" issues should now be fixed. If 
not, please reopen the bug with additional information. If the original bug 
covered multiple separate issues that aren't all addressed, please open new 
bug(s) for the leftover ones.

Original comment by Klaus.We...@gmail.com on 13 Jan 2012 at 9:29

GoogleCodeExporter commented 9 years ago 
Tested, still works as expected. Only minor polishing is needed. Like hints 
never going uppercase. And µ key is still shown when shifted, but long-press 
produces capital M somehow.

By the way, what about using the 5-row Alt key same as the "?123" key on the 
4-row layout to use the first of the popup letters? And another request, adding 
the shifted keys to popup for pucntuation on the 5-row view. I guess it'd be 
better if I opened a new issue, sorry. That's all.

Original comment by photo...@gmail.com on 16 Jan 2012 at 3:30

GoogleCodeExporter commented 9 years ago 
The hint labels are currently static and don't change based on shift state - 
fixing this would be doable but a bit annoying with 6 possible labels per key. 
In the meantime please think of them as painted-on labels, after all a hardware 
keyboard usually also doesn't update itself.

Original comment by Klaus.We...@gmail.com on 17 Jan 2012 at 6:40

GoogleCodeExporter commented 9 years ago 
Forgot to add - yes, please file separate issues or feature requests for your 
other suggestions. I'm planning on an AltGr key to replace Alt in text modes.

You've seen that the content of the long-press popups is now configurable, 
including an "add caps" option?

Original comment by Klaus.We...@gmail.com on 17 Jan 2012 at 6:45

GoogleCodeExporter commented 9 years ago 
Oh yeah, what I meant was adding shifted versions of punctuations only.

For the other things, I'll open seperate issues, and stay tuned for updates. 
Thanks for all hard work!

Original comment by photo...@gmail.com on 17 Jan 2012 at 10:05

GoogleCodeExporter commented 9 years ago 
Bulk update - changing "Fixed" to "Verified" for old bugs.

(Background: I'm changing the "Fixed" status to be considered open, the next 
steps in the lifecycle will be the closed states "FixInTest" and "Verified". 
This lets me mark issues as "Fixed" in commit messages without hiding them from 
the issue tracker.)

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:33

GoogleCodeExporter commented 9 years ago 
Bulk update - changing "Fixed" to "Verified" for old bugs.

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:34