Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:
 Well, I in the attached (very draft) patch I have cut and pasted
 feature (3) from GuiSpellChecker.cpp. It seems reasonable that the
 user install spellchecker modules for languages they want permanently
 in the Langauges menu. However converse it not true, as a user may be
 using a public machine where all languages have been installed. To
 deal with this I was thinking of limiting the languages added from the
 spellchecker to code to say 12, using a menu separator to split off
 from the languages actually used in the Document. Does this approach
 sound reasonable?

I prefer the session approach. I often use languages for which I do not have a 
spell checker dictionary installed. And I do not want all languages for which 
I have a dictionary in the menu (I might have installed the dictionaries even 
for another app than LyX). 

 Also the attached patch I have sorted the language by name. I think
 this makes the list easier to read, and also it makes your keyboard
 accelerator code work better. E.g. with the new sorting code I get:
   _English
   English (_UK)
 Rather than
   _English (UK)
   E_nglish
 In general your shortcut code will work better if parent languages
 appear before sub-languages:
 _Language
 Language (_Sublanguage)

Yes, the sorting makes sense.

 This patch also commented out the if (languages.size()  2) code. I
 recall that Lars didn't like dumping the user straight into the text
 style dialog box, but I don't like the idea of graying out the
 Languages dialog box, IMHO the user should always be able to set the
 Language from Edit-Languages.

No, we just removed that, and I think Jean-Marc put forward good reasons for 
this.

Jürgen

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:
> Well, I in the attached (very draft) patch I have cut and pasted
> feature (3) from GuiSpellChecker.cpp. It seems reasonable that the
> user install spellchecker modules for languages they want permanently
> in the Langauges menu. However converse it not true, as a user may be
> using a public machine where all languages have been installed. To
> deal with this I was thinking of limiting the languages added from the
> spellchecker to code to say 12, using a menu separator to split off
> from the languages actually used in the Document. Does this approach
> sound reasonable?

I prefer the session approach. I often use languages for which I do not have a 
spell checker dictionary installed. And I do not want all languages for which 
I have a dictionary in the menu (I might have installed the dictionaries even 
for another app than LyX). 

> Also the attached patch I have sorted the language by name. I think
> this makes the list easier to read, and also it makes your keyboard
> accelerator code work better. E.g. with the new sorting code I get:
>   _English
>   English (_UK)
> Rather than
>   _English (UK)
>   E_nglish
> In general your shortcut code will work better if parent languages
> appear before sub-languages:
> _Language
> Language (_Sublanguage)

Yes, the sorting makes sense.

> This patch also commented out the "if (languages.size() < 2)" code. I
> recall that Lars didn't like dumping the user straight into the text
> style dialog box, but I don't like the idea of graying out the
> Languages dialog box, IMHO the user should always be able to set the
> Language from Edit->Languages.

No, we just removed that, and I think Jean-Marc put forward good reasons for 
this.

Jürgen

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Guenter Milde]

On 2010-02-25, Jürgen Spitzmüller wrote:
 Jean-Marc Lasgouttes wrote:

Thanks for the work on the language menu, while there is still room for
improvement, I think it is going in the right direction.

 in the rather usual case when only one language is used ...
...
  This new menu entry is a regression in terms of usability IMO.

 If you think so, fine with me. I remebered that people do not easily find 
 that language is to be set in the character dialog.

Actually, I'd prefer to move the language setting out of the character
dialogue completely. Language is an important semantic feature, while all
other settings in this dialogue concern presentational markup.

Günter

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jean-Marc Lasgouttes]

Guenter Milde mi...@users.berlios.de writes:
 Actually, I'd prefer to move the language setting out of the character
 dialogue completely. Language is an important semantic feature, while all
 other settings in this dialogue concern presentational markup.

It makes sense.

JMarc

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Abdelrazak Younes]

On 02/26/2010 12:05 PM, Jean-Marc Lasgouttes wrote:

Guenter Mildemi...@users.berlios.de  writes:
   

Actually, I'd prefer to move the language setting out of the character
dialogue completely. Language is an important semantic feature, while all
other settings in this dialogue concern presentational markup.
 

It makes sense.
   


Yes, FWIW this the very reason why I created the language model in 
GuiApplication a while ago. Actually an old goal of mine was to use the 
language model in other dialogs. See this FIXME in GuiCharacter.cpp:129 :


static QListLanguagePair languageData()
{
QListLanguagePair list;
// FIXME (Abdel 14/05/2008): it would be nice if we could use this 
model
// directly in the language combo; but, as we need also the 'No 
Change' and

// 'Reset' items, this is not possible right now. Separating those two
// entries in radio buttons would be a better GUI IMHO.
QAbstractItemModel * language_model = guiApp-languageModel();

Re: #6558: Edit-Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 9:24 PM, Jürgen Spitzmüller sp...@lyx.org wrote:
snip
 3) On Linux/Ubuntu Languages that the user has installed
 language-packs for (or maybe aspell/hunspell packs)
 4) Languages that the user has configured input methods for.

 In my case this would mean that I always have English, English (UK),
 English (USA), French, German and Japanese as options, regardless of
 whether they already exist in the document.

 Yes, I thought about this, too. This would be an additional feature.
 (another possibility is that we store the used languages in session; so if
 you once selected your Englishes in a document, you'll always have them in
 the menu).

Well, I in the attached (very draft) patch I have cut and pasted
feature (3) from GuiSpellChecker.cpp. It seems reasonable that the
user install spellchecker modules for languages they want permanently
in the Langauges menu. However converse it not true, as a user may be
using a public machine where all languages have been installed. To
deal with this I was thinking of limiting the languages added from the
spellchecker to code to say 12, using a menu separator to split off
from the languages actually used in the Document. Does this approach
sound reasonable?

Also the attached patch I have sorted the language by name. I think
this makes the list easier to read, and also it makes your keyboard
accelerator code work better. E.g. with the new sorting code I get:
  _English
  English (_UK)
Rather than
  _English (UK)
  E_nglish
In general your shortcut code will work better if parent languages
appear before sub-languages:
_Language
Language (_Sublanguage)

This patch also commented out the if (languages.size()  2) code. I
recall that Lars didn't like dumping the user straight into the text
style dialog box, but I don't like the idea of graying out the
Languages dialog box, IMHO the user should always be able to set the
Language from Edit-Languages.

 However, this is something for later (at least as far as I am concerned).

I may as well paint the bikeshed now, while we are thinking about it :)

-- 
John C. McCabe-Dansted
Index: frontends/qt4/Menus.cpp
===
--- frontends/qt4/Menus.cpp	(revision 33588)
+++ frontends/qt4/Menus.cpp	(working copy)
@@ -50,6 +50,8 @@
 #include TocBackend.h
 #include Toolbars.h
 #include WordLangTuple.h
+#include SpellChecker.h
+#include Thesaurus.h
 
 #include insets/Inset.h
 #include insets/InsetCitation.h
@@ -760,23 +762,47 @@
 	
 }
 
+struct ltlang {
+	bool operator()(const Language *a, const Language *b) const {
+		return QString(a-display().c_str()).localeAwareCompare(b-display().c_str())  0;
+	}
+};
 
 void MenuDefinition::expandLanguageSelector(Buffer const * buf)
 {
 	if (!buf)
 		return;
 
-	std::setLanguage const * languages =
+	std::setLanguage const * languages_x =
 		buf-masterBuffer()-getLanguages();
 
-	if (languages.size()  2)
-		return;
+	std::setLanguage const *, ltlang languages;
 
+	std::setLanguage const *::const_iterator const begin_x = languages_x.begin();
+	for (std::setLanguage const *::const_iterator cit = begin_x;
+	 cit != languages_x.end(); ++cit) {
+		languages.insert(*cit);
+	}
+
+	Languages::const_iterator it = lyx::languages.begin();
+	Languages::const_iterator end = lyx::languages.end();
+	for (; it != end; ++it) {
+		if ( (theSpellChecker()  theSpellChecker()-hasDictionary(it-second)) ||
+(thesaurus.thesaurusInstalled(from_ascii(it-second.code( ) {
+			languages.insert(it-second);
+		}
+	}
+
+	// We may want to show the Language Menu anyway so we don't just
+	// Dump the user into the Text Style Dialog without warning.
+	//if (languages.size()  2)
+	//	return;
+
 	MenuItem item(MenuItem::Submenu, qt_(Language|L));
 	item.setSubmenu(MenuDefinition(qt_(Language)));
 	QStringList accelerators;
-	std::setLanguage const *::const_iterator const begin = languages.begin();
-	for (std::setLanguage const *::const_iterator cit = begin;
+	std::setLanguage const *, ltlang::const_iterator const begin = languages.begin();
+	for (std::setLanguage const *, ltlang::const_iterator cit = begin;
 	 cit != languages.end(); ++cit) {
 		QString label = qt_((*cit)-display());
 		// try to add an accelerator

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Guenter Milde]

On 2010-02-25, Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:

Thanks for the work on the language menu, while there is still room for
improvement, I think it is going in the right direction.

>> in the rather usual case when only one language is used ...
...
>>  This new menu entry is a regression in terms of usability IMO.

> If you think so, fine with me. I remebered that people do not easily find 
> that language is to be set in the character dialog.

Actually, I'd prefer to move the language setting out of the character
dialogue completely. Language is an important semantic feature, while all
other settings in this dialogue concern presentational markup.

Günter

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jean-Marc Lasgouttes]

Guenter Milde  writes:
> Actually, I'd prefer to move the language setting out of the character
> dialogue completely. Language is an important semantic feature, while all
> other settings in this dialogue concern presentational markup.

It makes sense.

JMarc

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Abdelrazak Younes]

On 02/26/2010 12:05 PM, Jean-Marc Lasgouttes wrote:

Guenter Milde  writes:
   

Actually, I'd prefer to move the language setting out of the character
dialogue completely. Language is an important semantic feature, while all
other settings in this dialogue concern presentational markup.
 

It makes sense.
   


Yes, FWIW this the very reason why I created the language model in 
GuiApplication a while ago. Actually an old goal of mine was to use the 
language model in other dialogs. See this FIXME in GuiCharacter.cpp:129 :


static QList languageData()
{
QList list;
// FIXME (Abdel 14/05/2008): it would be nice if we could use this 
model
// directly in the language combo; but, as we need also the 'No 
Change' and

// 'Reset' items, this is not possible right now. Separating those two
// entries in radio buttons would be a better GUI IMHO.
QAbstractItemModel * language_model = guiApp->languageModel();

Re: #6558: Edit->Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 9:24 PM, Jürgen Spitzmüller  wrote:

>> 3) On Linux/Ubuntu Languages that the user has installed
>> language-packs for (or maybe aspell/hunspell packs)
>> 4) Languages that the user has configured input methods for.
>>
>> In my case this would mean that I always have English, English (UK),
>> English (USA), French, German and Japanese as options, regardless of
>> whether they already exist in the document.
>
> Yes, I thought about this, too. This would be an additional feature.
> (another possibility is that we store the used languages in session; so if
> you once selected your Englishes in a document, you'll always have them in
> the menu).

Well, I in the attached (very draft) patch I have cut and pasted
feature (3) from GuiSpellChecker.cpp. It seems reasonable that the
user install spellchecker modules for languages they want permanently
in the Langauges menu. However converse it not true, as a user may be
using a public machine where all languages have been installed. To
deal with this I was thinking of limiting the languages added from the
spellchecker to code to say 12, using a menu separator to split off
from the languages actually used in the Document. Does this approach
sound reasonable?

Also the attached patch I have sorted the language by name. I think
this makes the list easier to read, and also it makes your keyboard
accelerator code work better. E.g. with the new sorting code I get:
  _English
  English (_UK)
Rather than
  _English (UK)
  E_nglish
In general your shortcut code will work better if parent languages
appear before sub-languages:
_Language
Language (_Sublanguage)

This patch also commented out the "if (languages.size() < 2)" code. I
recall that Lars didn't like dumping the user straight into the text
style dialog box, but I don't like the idea of graying out the
Languages dialog box, IMHO the user should always be able to set the
Language from Edit->Languages.

> However, this is something for later (at least as far as I am concerned).

I may as well paint the bikeshed now, while we are thinking about it :)

-- 
John C. McCabe-Dansted
Index: frontends/qt4/Menus.cpp
===
--- frontends/qt4/Menus.cpp	(revision 33588)
+++ frontends/qt4/Menus.cpp	(working copy)
@@ -50,6 +50,8 @@
 #include "TocBackend.h"
 #include "Toolbars.h"
 #include "WordLangTuple.h"
+#include "SpellChecker.h"
+#include "Thesaurus.h"
 
 #include "insets/Inset.h"
 #include "insets/InsetCitation.h"
@@ -760,23 +762,47 @@
 	
 }
 
+struct ltlang {
+	bool operator()(const Language *a, const Language *b) const {
+		return QString(a->display().c_str()).localeAwareCompare(b->display().c_str()) < 0;
+	}
+};
 
 void MenuDefinition::expandLanguageSelector(Buffer const * buf)
 {
 	if (!buf)
 		return;
 
-	std::set languages =
+	std::set languages_x =
 		buf->masterBuffer()->getLanguages();
 
-	if (languages.size() < 2)
-		return;
+	std::set languages;
 
+	std::set::const_iterator const begin_x = languages_x.begin();
+	for (std::set::const_iterator cit = begin_x;
+	 cit != languages_x.end(); ++cit) {
+		languages.insert(*cit);
+	}
+
+	Languages::const_iterator it = lyx::languages.begin();
+	Languages::const_iterator end = lyx::languages.end();
+	for (; it != end; ++it) {
+		if ( (theSpellChecker() && theSpellChecker()->hasDictionary(>second)) ||
+(thesaurus.thesaurusInstalled(from_ascii(it->second.code( ) {
+			languages.insert(>second);
+		}
+	}
+
+	// We may want to show the Language Menu anyway so we don't just
+	// Dump the user into the Text Style Dialog without warning.
+	//if (languages.size() < 2)
+	//	return;
+
 	MenuItem item(MenuItem::Submenu, qt_("Language|L"));
 	item.setSubmenu(MenuDefinition(qt_("Language")));
 	QStringList accelerators;
-	std::set::const_iterator const begin = languages.begin();
-	for (std::set::const_iterator cit = begin;
+	std::set::const_iterator const begin = languages.begin();
+	for (std::set::const_iterator cit = begin;
 	 cit != languages.end(); ++cit) {
 		QString label = qt_((*cit)->display());
 		// try to add an accelerator

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:
 A couple of questions:
 1) Is using _(() enough to make the code sufficiently multilingual?

 I doubt it. But you can try yourself. Just try different LANG environments.

BTW, I just tried this language selector thing, only to find out that,
in the rather usual case when only one language is used, it adds an ugly
Language... entry that just opens the character dialog. I think it would
be better the gray out of remove the entry in this case. This new menu
entry is a regression in terms of usability IMO.

JMarc

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 BTW, I just tried this language selector thing, only to find out that,
 in the rather usual case when only one language is used, it adds an ugly
 Language... entry that just opens the character dialog. I think it would
 be better the gray out of remove the entry in this case. This new menu
 entry is a regression in terms of usability IMO.

If you think so, fine with me. I remebered that people do not easily find 
that language is to be set in the character dialog.

Jürgen

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

 In the worst case we could enumerate the options. Heck I'd even find
 1:  English
 2: English (UK)
 3: English (USA)
 4: English (Canada)
 More meaningful than
 _English
 E_nglish (UK)
 En_glish (USA)
 Eng_lish (Canada)

I don't. Remember these are _menu_ accelerators. The menus often do not use 
mnemotics, but rather what is available (since you do not have to meorize 
these accelerators while you see the menu).

Proper key accelerators (Such as Alt+L e) would need to be added anyway 
(in addition to the menu). I mean Alt+E+L+E is still too clumsy (and this is 
not where this menu aims at).

 An approach which avoids using '(' would be to represent the languages
 as a tree, and put the _ before the first available alpha-numeric
 character in the string e.g.
 {
 { _English
 { (_Canada)
 { (U
 {_K) }
 {_SA)}
 }
 }
 { _French }
 }
 
 resulting in:
 _English
 English (_Canada)
 English (U_K)
 Engish (U_SA)
 _French
 
 Would this approach be preferred?

I think we can do that better with Qt's help. I'll have a look.

Jürgen

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:

 I think we can do that better with Qt's help. I'll have a look.

try revision 33566.

Jürgen

Re: #6558: Edit-Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 8:34 PM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Jean-Marc Lasgouttes wrote:

 BTW, I just tried this language selector thing, only to find out that,
 in the rather usual case when only one language is used, it adds an ugly
 Language... entry that just opens the character dialog. I think it would
 be better the gray out of remove the entry in this case. This new menu
 entry is a regression in terms of usability IMO.

 If you think so, fine with me. I remebered that people do not easily find
 that language is to be set in the character dialog.

My feeling also was that people may be confused if the Languages was
grayed out. Often when using a GUI I have been confused as to why a
particular item has been grayed out, and existing toolkits don't seem
to encourage developers to give explanations of why items are grayed
out.

I can imagine a user going:
   OK, the Languages is grayed out, maybe LyX uses the OO lang packs,
I'll install those. Nup didn't work. Maybe the GIMP lang packs? OK,
I'll try installing *all* the lang packs my distro provides, one of
them must the right one. Huh, still doesn't work? Hmm, maybe I need to
recompile ...

Perhaps the Languages menu should always have certain important
languages available, including for example
  1) The LyX Interface Language
  2) The System default language
  3) On Linux/Ubuntu Languages that the user has installed
language-packs for (or maybe aspell/hunspell packs)
  4) Languages that the user has configured input methods for.

In my case this would mean that I always have English, English (UK),
English (USA), French, German and Japanese as options, regardless of
whether they already exist in the document.

-- 
John C. McCabe-Dansted

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:

 Jean-Marc Lasgouttes wrote:

 BTW, I just tried this language selector thing, only to find out that,
 in the rather usual case when only one language is used, it adds an ugly
 Language... entry that just opens the character dialog. I think it would
 be better the gray out of remove the entry in this case. This new menu
 entry is a regression in terms of usability IMO.

 If you think so, fine with me. I remebered that people do not easily find 
 that language is to be set in the character dialog.

I agree that the character dialog is awful, but it is not a reason for
forcing it in the throat of people who are just looking for setting
language.

Thanks for changing that. Another solution could be to have at top-level
the language that are used in the buffer and a submenu with all the
_other_ languages. This would allow easy selection of a still unused
language too.

JMarc

Re: #6558: Edit-Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 8:56 PM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Jürgen Spitzmüller wrote:

 I think we can do that better with Qt's help. I'll have a look.

 try revision 33566.

Looks good.

I notice that you've added an accelerator to More Languages too :).

Malay and More Languages  share the  accelerator M, but Qt
Handles this gracefully so I don't think it is worth fixing.

-- 
John C. McCabe-Dansted

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 Thanks for changing that. Another solution could be to have at top-level
 the language that are used in the buffer and a submenu with all the
 other languages. This would allow easy selection of a still unused
 language too.

Yes, but we have a lot of languages. And the top menu can get quite long 
(think of the context menu if continuous spellchecking is on).

Jürgen

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

 Perhaps the Languages menu should always have certain important
 languages available, including for example
 1) The LyX Interface Language
 2) The System default language
 3) On Linux/Ubuntu Languages that the user has installed
 language-packs for (or maybe aspell/hunspell packs)
 4) Languages that the user has configured input methods for.
 
 In my case this would mean that I always have English, English (UK),
 English (USA), French, German and Japanese as options, regardless of
 whether they already exist in the document.

Yes, I thought about this, too. This would be an additional feature.
(another possibility is that we store the used languages in session; so if 
you once selected your Englishes in a document, you'll always have them in 
the menu).

However, this is something for later (at least as far as I am concerned).

Jürgen

RE: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

Consider this a bug..

I understood ;-)

 I already did..
 
OK?
 
 Yes.

It's in.

Jürgen

RE: #6558: Edit-Language lacks keyboard shortcuts.

[Vincent van Ravesteijn - TNW]

 And in the less usual case in which only languages are used other than 
 the document language, the document language is not in the list (which 
 I would expect of course).

Consider this a bug..

I already did..

OK?

Yes.

Jürgen

Vincent

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:
>> A couple of questions:
>> 1) Is using _("(") enough to make the code sufficiently multilingual?
>
> I doubt it. But you can try yourself. Just try different LANG environments.

BTW, I just tried this language selector thing, only to find out that,
in the rather usual case when only one language is used, it adds an ugly
Language... entry that just opens the character dialog. I think it would
be better the gray out of remove the entry in this case. This new menu
entry is a regression in terms of usability IMO.

JMarc

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

> BTW, I just tried this language selector thing, only to find out that,
> in the rather usual case when only one language is used, it adds an ugly
> Language... entry that just opens the character dialog. I think it would
> be better the gray out of remove the entry in this case. This new menu
> entry is a regression in terms of usability IMO.

If you think so, fine with me. I remebered that people do not easily find 
that language is to be set in the character dialog.

Jürgen

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

> In the worst case we could enumerate the options. Heck I'd even find
> 1:  English
> 2: English (UK)
> 3: English (USA)
> 4: English (Canada)
> More meaningful than
> _English
> E_nglish (UK)
> En_glish (USA)
> Eng_lish (Canada)

I don't. Remember these are _menu_ accelerators. The menus often do not use 
mnemotics, but rather "what is available" (since you do not have to meorize 
these accelerators while you see the menu).

Proper key accelerators (Such as "Alt+L e") would need to be added anyway 
(in addition to the menu). I mean Alt+E+L+E is still too clumsy (and this is 
not where this menu aims at).

> An approach which avoids using '(' would be to represent the languages
> as a tree, and put the _ before the first available alpha-numeric
> character in the string e.g.
> {
> { "_English"
> { "(_Canada)"
> { "(U"
> {"_K)" }
> {"_SA)"}
> }
> }
> { "_French" }
> }
> 
> resulting in:
> _English
> English (_Canada)
> English (U_K)
> Engish (U_SA)
> _French
> 
> Would this approach be preferred?

I think we can do that better with Qt's help. I'll have a look.

Jürgen

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:

> I think we can do that better with Qt's help. I'll have a look.

try revision 33566.

Jürgen

Re: #6558: Edit->Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 8:34 PM, Jürgen Spitzmüller  wrote:
> Jean-Marc Lasgouttes wrote:
>
>> BTW, I just tried this language selector thing, only to find out that,
>> in the rather usual case when only one language is used, it adds an ugly
>> Language... entry that just opens the character dialog. I think it would
>> be better the gray out of remove the entry in this case. This new menu
>> entry is a regression in terms of usability IMO.
>
> If you think so, fine with me. I remebered that people do not easily find
> that language is to be set in the character dialog.

My feeling also was that people may be confused if the "Languages" was
grayed out. Often when using a GUI I have been confused as to why a
particular item has been grayed out, and existing toolkits don't seem
to encourage developers to give explanations of why items are grayed
out.

I can imagine a user going:
   "OK, the Languages is grayed out, maybe LyX uses the OO lang packs,
I'll install those. Nup didn't work. Maybe the GIMP lang packs? OK,
I'll try installing *all* the lang packs my distro provides, one of
them must the right one. Huh, still doesn't work? Hmm, maybe I need to
recompile ..."

Perhaps the Languages menu should always have certain important
languages available, including for example
  1) The LyX Interface Language
  2) The System default language
  3) On Linux/Ubuntu Languages that the user has installed
language-packs for (or maybe aspell/hunspell packs)
  4) Languages that the user has configured input methods for.

In my case this would mean that I always have English, English (UK),
English (USA), French, German and Japanese as options, regardless of
whether they already exist in the document.

-- 
John C. McCabe-Dansted

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:

> Jean-Marc Lasgouttes wrote:
>
>> BTW, I just tried this language selector thing, only to find out that,
>> in the rather usual case when only one language is used, it adds an ugly
>> Language... entry that just opens the character dialog. I think it would
>> be better the gray out of remove the entry in this case. This new menu
>> entry is a regression in terms of usability IMO.
>
> If you think so, fine with me. I remebered that people do not easily find 
> that language is to be set in the character dialog.

I agree that the character dialog is awful, but it is not a reason for
forcing it in the throat of people who are just looking for setting
language.

Thanks for changing that. Another solution could be to have at top-level
the language that are used in the buffer and a submenu with all the
_other_ languages. This would allow easy selection of a still unused
language too.

JMarc

Re: #6558: Edit->Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 8:56 PM, Jürgen Spitzmüller  wrote:
> Jürgen Spitzmüller wrote:
>
>> I think we can do that better with Qt's help. I'll have a look.
>
> try revision 33566.

Looks good.

I notice that you've added an accelerator to "More Languages" too :).

"Malay" and "More Languages"  share the  accelerator "M", but Qt
Handles this gracefully so I don't think it is worth "fixing".

-- 
John C. McCabe-Dansted

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

> Thanks for changing that. Another solution could be to have at top-level
> the language that are used in the buffer and a submenu with all the
> other languages. This would allow easy selection of a still unused
> language too.

Yes, but we have a lot of languages. And the top menu can get quite long 
(think of the context menu if continuous spellchecking is on).

Jürgen

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

> Perhaps the Languages menu should always have certain important
> languages available, including for example
> 1) The LyX Interface Language
> 2) The System default language
> 3) On Linux/Ubuntu Languages that the user has installed
> language-packs for (or maybe aspell/hunspell packs)
> 4) Languages that the user has configured input methods for.
> 
> In my case this would mean that I always have English, English (UK),
> English (USA), French, German and Japanese as options, regardless of
> whether they already exist in the document.

Yes, I thought about this, too. This would be an additional feature.
(another possibility is that we store the used languages in session; so if 
you once selected your Englishes in a document, you'll always have them in 
the menu).

However, this is something for later (at least as far as I am concerned).

Jürgen

RE: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

>>Consider this a bug..

I understood ;-)

> I already did..
> 
>>OK?
> 
> Yes.

It's in.

Jürgen

RE: #6558: Edit->Language lacks keyboard shortcuts.

[Vincent van Ravesteijn - TNW]

>> And in the less usual case in which only languages are used other than 
>> the document language, the document language is not in the list (which 
>> I would expect of course).

>Consider this a bug..

I already did..

>OK?

Yes.

>Jürgen

Vincent

Re: #6558: Edit-Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Wed, Feb 24, 2010 at 10:08 PM, LyX Ticket Tracker t...@lyx.org wrote:
 #6558: Edit-Language lacks keyboard shortcuts.
snip
  I implemented a simpler solution (ignoring the casing) at r33555.
snip
 Ticket URL: http://www.lyx.org/trac/ticket/6558#comment:2

OK, but adding a couple of lines of code makes this much nicer for
English users. E.g.
-   for (int i = 0; i  label.size(); ++i) {
+
+   docstring paren = _(();
+   const int start_at = label.indexOf(to_utf8(paren).c_str()) + 1;
+   for (int i = start_at; i  label.size(); ++i) {

The above patch means that I have
_English
English (_UK)
which I find much more meaningful than:
   _English
   E_nglsh (UK)

It does however have a regression, as Canadians may find the original
behavior better than
   English (_Canadian)
   French (C_anadian)

Also I think it would look nicer if it output
  Chinese (_Simplified)
rather than
  Chine_se (Simplified)
but Qt doesn't seem to support this.

A couple of questions:
1) Is using _(() enough to make the code sufficiently multilingual?
2) Would you like an improved patch that achieves the above without
introducing the Canadian regression?

-- 
John C. McCabe-Dansted

Re: #6558: Edit-Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

 OK, but adding a couple of lines of code makes this much nicer for
 English users. 

But we do not only have English users. I'm not even sure my current approach 
is suitable for all localizations. I think Japanese uses roman accelerators, 
but the strings are non-roman (of course). I do not see how we can provide 
this with an automated approach.

 A couple of questions:
 1) Is using _(() enough to make the code sufficiently multilingual?

I doubt it. But you can try yourself. Just try different LANG environments.

Jürgen

Re: #6558: Edit-Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 6:07 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
 OK, but adding a couple of lines of code makes this much nicer for
 English users.

 But we do not only have English users.

Right, but English is the language I can test with confidence.

 I'm not even sure my current approach
 is suitable for all localizations. I think Japanese uses roman accelerators,

correct. It there a test to see if the characters are easy to enter? I
guess [a-zA-Z] is not sufficient, when I went to Europe I remember
that the keyboards had keys for common accented characters, I guess
you can type ü with a single keypress? In which case using
to_ascii and/or excluding characters not in [a-zA-Z] would not
always help.

 but the strings are non-roman (of course). I do not see how we can provide
 this with an automated approach.

In the worst case we could enumerate the options. Heck I'd even find
  1:  English
  2: English (UK)
  3: English (USA)
  4: English (Canada)
More meaningful than
  _English
  E_nglish (UK)
  En_glish (USA)
  Eng_lish (Canada)

 A couple of questions:
 1) Is using _(() enough to make the code sufficiently multilingual?

 I doubt it. But you can try yourself. Just try different LANG environments.

Hmm, actually with the LyX-1.6 interface at least the _(() seems overkill.

The French, German and Japanese translations all just use '('.

However I cannot internationalize the versions of LyX that I have
compiled myself, so I can't test trunk easily.

An approach which avoids using '(' would be to represent the languages
as a tree, and put the _ before the first available alpha-numeric
character in the string e.g.
{
  { _English
{ (_Canada)
   { (U
  {_K) }
  {_SA)}
   }
}
  { _French }
}

resulting in:
  _English
  English (_Canada)
  English (U_K)
  Engish (U_SA)
  _French

Would this approach be preferred?

-- 
John C. McCabe-Dansted

Re: #6558: Edit->Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Wed, Feb 24, 2010 at 10:08 PM, LyX Ticket Tracker  wrote:
> #6558: Edit->Language lacks keyboard shortcuts.

>  I implemented a simpler solution (ignoring the casing) at r33555.

> Ticket URL: 

OK, but adding a couple of lines of code makes this much nicer for
English users. E.g.
-   for (int i = 0; i < label.size(); ++i) {
+
+   docstring paren = _("(");
+   const int start_at = label.indexOf(to_utf8(paren).c_str()) + 1;
+   for (int i = start_at; i < label.size(); ++i) {

The above patch means that I have
_English
English (_UK)
which I find much more meaningful than:
   _English
   E_nglsh (UK)

It does however have a regression, as Canadians may find the original
behavior better than
   English (_Canadian)
   French (C_anadian)

Also I think it would look nicer if it output
  Chinese (_Simplified)
rather than
  Chine_se (Simplified)
but Qt doesn't seem to support this.

A couple of questions:
1) Is using _("(") enough to make the code sufficiently multilingual?
2) Would you like an improved patch that achieves the above without
introducing the Canadian regression?

-- 
John C. McCabe-Dansted

Re: #6558: Edit->Language lacks keyboard shortcuts.

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

> OK, but adding a couple of lines of code makes this much nicer for
> English users. 

But we do not only have English users. I'm not even sure my current approach 
is suitable for all localizations. I think Japanese uses roman accelerators, 
but the strings are non-roman (of course). I do not see how we can provide 
this with an automated approach.

> A couple of questions:
> 1) Is using _("(") enough to make the code sufficiently multilingual?

I doubt it. But you can try yourself. Just try different LANG environments.

Jürgen

Re: #6558: Edit->Language lacks keyboard shortcuts.

[John McCabe-Dansted]

On Thu, Feb 25, 2010 at 6:07 AM, Jürgen Spitzmüller  wrote:
>> OK, but adding a couple of lines of code makes this much nicer for
>> English users.
>
> But we do not only have English users.

Right, but English is the language I can test with confidence.

> I'm not even sure my current approach
> is suitable for all localizations. I think Japanese uses roman accelerators,

correct. It there a test to see if the characters are easy to enter? I
guess [a-zA-Z] is not sufficient, when I went to Europe I remember
that the keyboards had keys for common accented characters, I guess
you can type "ü" with a single keypress? In which case using
"to_ascii" and/or excluding characters not in [a-zA-Z] would not
always help.

> but the strings are non-roman (of course). I do not see how we can provide
> this with an automated approach.

In the worst case we could enumerate the options. Heck I'd even find
  1:  English
  2: English (UK)
  3: English (USA)
  4: English (Canada)
More meaningful than
  _English
  E_nglish (UK)
  En_glish (USA)
  Eng_lish (Canada)

>> A couple of questions:
>> 1) Is using _("(") enough to make the code sufficiently multilingual?
>
> I doubt it. But you can try yourself. Just try different LANG environments.

Hmm, actually with the LyX-1.6 interface at least the _("(") seems overkill.

The French, German and Japanese translations all just use '('.

However I cannot internationalize the versions of LyX that I have
compiled myself, so I can't test trunk easily.

An approach which avoids using '(' would be to represent the languages
as a tree, and put the _ before the first available alpha-numeric
character in the string e.g.
{
  { "_English"
{ "(_Canada)"
   { "(U"
  {"_K)" }
  {"_SA)"}
   }
}
  { "_French" }
}

resulting in:
  _English
  English (_Canada)
  English (U_K)
  Engish (U_SA)
  _French

Would this approach be preferred?

-- 
John C. McCabe-Dansted