Closed phikal closed 7 years ago
Whew, that's a long description. Let's answer one by one.
[...] the drop down list doesn’t seem to contain all string IDs
app_name
probably has translatable="false"
. These strings are not shown. In the case of title_activity_game
, it was probably translated already. Strings that are already translated are not shown. You can show all the strings by tapping on "Show translated strings". If you have this check box ticked and still happens, please reply back!
I couldn't access the English (or default) locale, since this wasn't offered in the drop Selected locale drop down list.
Yes, default (usually English), since that is the default locale, you can't choose to translate to it, but rather use it to translate it. Again, check "Show translated strings" if you want to see all IDs.
[...] use most of the screen for the Current string IDs, by replacing the drop down list with list view?
I think that would make the activity way too big. Some applications have hundreds of strings, imagine scrolling up and down all the time when changing the ID and then back to the translation field!
I believe this layout would make more sense for a new user
Could you do a sketch? Maybe I don't quite see your point.
[...] and would give a better overview of what has and hasn't been translated.
Next version comes with a new progress bar for that, no worries :)
I'd gladly make a sketch for you.
You actually mentioned this later 😆, yes please make a sketch.
app_name probably has translatable="false". These strings are not shown.
I took a closer look at the code I was testing this with, and realized that app_name
was translated in some languages, and wasn't in others, since the app name doesn't change from app to app.
Strings that are already translated are not shown. You can show all the strings by tapping on "Show translated strings". If you have this check box ticked and still happens, please reply back!
Yeah, this solved it. But all in all, this seemed to be an unintuitive way to present the strings, or at least confused me. This was on of the reasons I thought the UI could be "improved".
I think that would make the activity way too big. Some applications have hundreds of strings, imagine scrolling up and down all the time when changing the ID and then back to the translation field!
Could you do a sketch? Maybe I don't quite see your point.
I hope this makes the idea more understandable.
The part below the big blue dashed box, would be fixed, and wouldn't move with the scroll view.
All in all, I think that this kind of layout would use the screen-space more efficiently, and would make more sense to a new user.
this seemed to be an unintuitive way to present the strings
I thought hiding the strings that already had a translation would make it easier to translate only those which don't have a translation. If any had a typo, you could always enable the "Show translated strings". Should I leave README.md
clearer perhaps? Any other option?
That's why I suggested that the translation panel would stay at the bottom of the screen
Ah, you meant to let it be a "sticky" view. I wonder if this would cause issues on very large strings which make both the original string and translated string EditText
's very large.
[Sketch]
What would happen when 1. the keyboard is shown and 2. you're translating a very long string? Without these two points, it does look nicer. A ListView
like the one you drew being animated into a single item showing the current string when the keyboard is open would be a bit overkill, wouldn't it?
Edit: Btw gotta say this, nice sketch.
Should I leave README.md clearer perhaps? Any other option?
Either in the README or in some other introduction manual. Alternatively it could also be mentioned in a first-instalation popup, or something like that.
- the keyboard is shown
In this case, I'd imagine that the ListView
would either "disappear" or just set it's hight to 0 (ie. the ListView
would have some kind of a minimal hight). The result would be that while they keyboard is opened and the screen can't display both translation panel & string list, that only the translation panel would be shown.
Ah, you meant to let it be a "sticky" view. I wonder if this would cause issues on very large strings which make both the original string and translated string EditText's very large.
- you're translating a very long string
One could either make the translation panel scrollable, or (what I think would be the better idea), one could add a button to start a new translation activity just for this one strings. I'd imagine this button to be some kind of a "maximize" icon, in the upper-right corner.
A ListView like the one you drew being animated into a single item showing the current string when the keyboard is open would be a bit overkill, wouldn't it?
Generally yes, but I'd say it also depends on the screen dimensions. A tablet or a maybe even a bigger phone would maybe fit both on the screen.
I'll take some time to think how it could be done in a nice way.
If you still have doubts about how "Show translated strings" works @phikal, you can now check the new help section I've just added.
I would like to discuss this a bit more @phikal.
I was thinking that perhaps we could even animate some elements, such as the ListView
itself, the EditText
's, and let the other elements fade away when the keyboard is shown. However:
< 5.0
devices.ListView
? What if it's one and half, which is annoying to scroll on? How shall it behave on screens with different dp
's?Translate
activity is already over 700 lines of code and there even isn't so many things in it! (700 might not be that much, but animating so many things doesn't sound easy anyway).EditText
's, selecting text is a bit hard on phone devices.Something else I wanted to do was to add the ability to search for a string
ID, or maybe even its contents (say to fix a typo). Here is where a ListView
would really come handy. And I did like your sketch.
How would it be to have another activity based on two fragments (just like the main activity), but without the tab names shown (to have more space). Left fragment as is, and right fragment your ListView
+ some search. All strings shown by default (maybe some different background color to indicate whether it's been translated). To change between the fragments, you would simply swipe. This is something users should discover, or maybe some hint for the first time (although I don't know where it could be shown).
Thoughts? Ideas? Thanks in advance!
Could you explain what exactly you mean with "animate"?
There is not a "real" way to detect the keyboard being shown. Solutions out there "cheat" by calculating the difference of height. Not so reliable. Also, some keyboards may have really weird shapes.
I'd say there is: checking if the EditText
view has focus or not? Or could this go wrong?
But what value should this be? Only one item visible on the ListView? What if it's one and half, which is annoying to scroll on? How shall it behave on screens with different dp's?
One could maybe calculate the hight of the child views within the list (within the Java code that is), and then specify a minimal amount of items. Then you'd have something like if (heigh(listView) < 48dp * 3) ...
.
But if one would use the focus method, this question would rather be relevant in the opposite situation: how many elements should still fit on the screen, to display them even if the the keyboard it shown.
I'm not really sure how maintainable this would be, the Translate activity is already over 700 lines of code and there even isn't so many things in it! (700 might not be that much, but animating so many things doesn't sound easy anyway).
How would it be to have another activity based on two fragments (just like the main activity), but without the tab names shown (to have more space). Left fragment as is, and right fragment your ListView + some search.
Personally, I've never been to much of a fan of having tabs for connected a task like this, and I'm not sure if this would match the Android guidelines? Wouldn’t it make more sense to have an own activity (with swiping) or a quick pop-up? But that's just my opinion.
This is something users should discover, or maybe some hint for the first time (although I don't know where it could be shown).
Don't some application have this tutorial function when started for the first time, guiding the user through the usage? I've never found out what library they use for this, so I'm not sure how easily this could be done.
Could you explain what exactly you mean with "animate"?
By "animate" I mean a transition. Basically seeing the element move across the screen. Not letting it happen instantly.
checking if the
EditText
view has focus or not?
That's actually simpler, and it wouldn't really matter if the keyboard is not shown yet or whatever. EditText
focused = more space.
I believe the Focus method would require far less code and would cause less maintenance problems.
Yes, agree, I like that.
I've never been to much of a fan of having tabs for connected a task like this
Think of it as a way to search for strings, rather than simply displaying available ones (which is already done on the Spinner
).
or a quick pop-up?
Spinner is sort of a pop-up already; just that it doesn't fill the whole screen.
Edit:
Don't some application have this tutorial function when started for the first time, guiding the user through the usage?
If I put the Search action on the menu, and when it was clicked it automatically swiped to the right fragment I mentioned above (ListView
+ search bar), then we wouldn't need to add any kind of tutorial. The user would see they could actually do that. Or even not being able to swipe, but the other fragment slides in.
To be honest I like the layout how it is, I think adding a ListView
there is a bit too much. But yes, I'm talking about phone and not tablet devices. However I also liked how the ListView
looks, so that's why I'm trying to put it somewhere else.
Think of it as a way to search for strings, rather than simply displaying available ones (which is already done on the Spinner).
Spinner is sort of a pop-up already; just that it doesn't fill the whole screen.
^^ I was referring to the whole setup, or at least they way I understood it (but I'm not sure I imagined in correctly, but nevermind). I also think a search function + the list view would help the user to orient themselves.
(but I'm not sure I imagined in correctly, but nevermind)
alwaysmind, here you go:
Ah, ok this makes sense. I thought you were thinking of tabs like in the main activity. Meaning that one would have to swipe left and right all the time. I suppose that on tablets or bigger screens one would then be able to place both next/under eachother?
And can I ask what the three squares are representing on the
I thought you were thinking of tabs like in the main activity.
I did, just not showing the tab names (so that part is hidden).
I suppose that on tablets or bigger screens one would then be able to place both next/under eachother?
I have never worked on "dual" layouts for both phone and tablet, but I've seen Telegram screenshots for tablet devices and the ListView
could be on the left being the right side for the translation process.
And can I ask what the three squares are representing on the
Previous, Save and Next buttons. Didn't fill in the labels.
@phikal feedback?
I tried to convert the Translate activity to a fragment. It works. But it's been a pain and if I rebased the changes then I would have to fix quite a few conflicts. If anyone wants to have a dual panel for tablet devices, then they can implement it; fragments are horrible!
This is going to be an Activity which gets fired when you press Search on the Translate activity. Then you can enter a search term, look for the string you want, select it and go back to the translation process.
Maybe a slightly larger font for the values?
Edit: By the way the action bar title will be a ComboBox
/Spinner
to select a different locale too.
feedback?
Overall it looks great, but I'll note two things that caught my eye:
The search area has something wierd to it... Maybe it's the magnifying glass, or the fact that there is no clear border towards the ListView
/the action bar has no use (at least in this screenshot)... I personally would have used those search functions built into the action bar, but that would be weird in, since "This is going to be an Activity which gets fired when you press Search on the Translate activity". Maybe one could launch the search function with the activity itself?
The items withing the ListView
either aren't using up their space efficiently, or should be centered vertically. The fact that there seems to be more padding on the top, than on the bottom, just seemed wired, and stuck out. Furthermore, how do these Items scale to longer translations? Finally, I'd question why the left hand translation "gives in" the the String ID? Some of these (like apps_repo_not_downloaded
) could be using up too much space, while the original string can't be displayed.
fragments are horrible!
I know ^^
This is going to be an Activity which gets fired when you press Search on the Translate activity. Then you can enter a search term, look for the string you want, select it and go back to the translation process.
So what does the Translate activity contain as of now?
Maybe a slightly larger font for the values?
I don't think this is necessary, I'd rather try something like what I mentioned in the second point above.
or the fact that there is no clear border towards the
ListView
Yeah it would look better with some margin.
I personally would have used those search functions built into the action bar
Nah, let's reserve that for a spinner containing the locales as you sketched. I liked it.
Maybe one could launch the search function with the activity itself?
What did you mean?
The fact that there seems to be more padding on the top, than on the bottom
The padding is now the same, more or less. I don't know why there is no such thing as ?attr/listPreferredItemPaddingTop
, as there is for Left
and Right
Furthermore, how do these Items scale to longer translations?
It's a single line, so the text is trimmed and ...
placed at the end.
why the left hand translation "gives in" the the String ID?
Maybe the string ID
should be on the bottom below the translation and gravity="end"
?
So what does the Translate activity contain as of now?
Same as before, but with a new super fancy white search button which you can tap as many times as you want!
Whew, those were big changes. I know this isn't exactly what you had in mind, but I'm happy with the result so thanks for the idea :)
I tried to open Stringlate for a already translated language (danish, in this case), but the drop down list doesn’t seem to contain all string IDs, like
title_activity_game
orapp_name
:Interestingly enough, when I created a new locale (in this case Russian), all IDs were listed.
Furthermore, I couldn't access the English (or default) locale, since this wasn't offered in the drop
Selected locale
drop down list.Just a extra suggestion, layout wise: wouldn't it make more sense to use most of the screen for the
Current string ID
s, by replacing the drop down list with list view? One could then move the locale selection up into the action bar, and reserve some space at the bottom for all the stuff related to actually translating the strings. I believe this layout would make more sense for a new user, and would give a better overview of what has and hasn't been translated.In case my description was too vague or you couldn't imagine it for some other reason, I'd gladly make a sketch for you.