I18N usability issue

I've always thought the requirement to enable the "hardcoded string literal"
inspection to i18nize strings via QuickFix is quite hard to find for an average
user.

Now, since the "I18nize JSP Text" appeared in the refactoring menu, this is not
only non-obvious but also additionally confusing because one part of the I18N
functionality is available via the refactoring menu while another one is not. I
even dare to say that the less common functionality for JSP is easier and more
obvious to find than the one for plain Java.

I think this needs some thought how to make this more consistent, convenient to
use and easier to find for a new user. Unfortunately, I don't have a good
solution other than simply adding an "I18N" submenu to the refactoring menu and
putting both the i18nize actions for JSP and Java in it.

Talking about the refactoring menu, this has been getting fairly long these days
(especially with Refactor-J), so it might be worth to consider putting some less
frequently used actions into an "Advanced" (or similar) submenu.

Anyway, just some food for thought.

Sascha

8 comments

Sascha, how about universal action 'i18nize selection' which either delegates to 'i18nize JSP text' or 'i18nize (sub)selection in Java string literal' actions context-sensitively ?

0

Hello Alexey,

I agree with Saschas comments, and think that your suggestion would be a
nice improvement.

Sascha, how about universal action 'i18nize selection' which either
delegates to 'i18nize JSP text' or 'i18nize (sub)selection in Java
string literal' actions context-sensitively ?



0

Hi Alexey,
+100 and taking in account efforts to implement may be incorporated into 5.1 thought :)

Thanks,
Dmitry

0

Alexey Kudravtsev wrote:

Sascha, how about universal action 'i18nize selection' which either delegates to 'i18nize JSP text' or 'i18nize (sub)selection in Java string literal' actions context-sensitively ?


That's probably a good solution, and it should tell the user about the
context-sensitivity in the action-description in the statusbar.

Sascha

0

BTW, could you provide the use-case for i18nizing the selected (strict) substring?
Would not it be clearer not to base 'i18nize' action on current editor selection, and i18nize whole string literal?
If you still want only substring i18nization, break the string up to the needed substrings before the action invocation (matter of couple of enter presses).

0

Alexey Kudravtsev wrote:

BTW, could you provide the use-case for i18nizing the selected (strict) substring?
Would not it be clearer not to base 'i18nize' action on current editor selection, and i18nize whole string literal?
If you still want only substring i18nization, break the string up to the needed substrings before the action invocation (matter of couple of enter presses).


I think that this falls into basic consistency and usability.

- If I have a selection and I invoke an action, I expect it to operate on the selection.
- If I don't have a selection and I invoke an action , I expect it to operate on the
appropriate scope that my cursor in contained within. (ie. the whole string literal).

0

Fixed.
(Unfortunately could not make it to the 5.1)

--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"

"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:ds02sk$tu6$1@is.intellij.net...

Alexey Kudravtsev wrote:

>> Sascha, how about universal action 'i18nize selection' which either
>> delegates to 'i18nize JSP text' or 'i18nize (sub)selection in Java string
>> literal' actions context-sensitively ?
>

That's probably a good solution, and it should tell the user about the
context-sensitivity in the action-description in the statusbar.

>

Sascha



0

Alexey Kudravtsev wrote:

BTW, could you provide the use-case for i18nizing the selected (strict) substring?
Would not it be clearer not to base 'i18nize' action on current editor selection, and i18nize whole string literal?
If you still want only substring i18nization, break the string up to the needed substrings before the action invocation (matter of couple of enter presses).


Hey, it was you who came up with the possibility to i18n substrings ;)

I agree that this is probably not the most common use-case, but why force the
user to do something the IDE can do as well? I think it's pretty safe to assume
that the user indeed wants to i18n the selected substring if a selection exists,
so what speaks against just doing it? That's actually always been one of IDEA's
strengths that certain things just work without any additional steps ("couple
of enter presses").

Sascha

0

Please sign in to leave a comment.