[Scribus] Spell checking
Mon May 21 11:52:05 CEST 2007
2007/5/20, avox <avox at arcor.de>:
> Gora Mohanty-3 wrote:
> > Hi,
> > I have a first-cut version of the spell-checking plugin which seems to
> > be working. I need to add a mechanism to get text from Scribus, and run
> > it through the spell-checker. Petr has pointed me to the shortwords
> > plugin, and I will try to work that in over the next couple of days.
> > On Sat, 2007-05-19 at 09:46 -0400, Louis Desjardins wrote:
> >> 2007/5/18, avox <avox at arcor.de>:
> > [...]
> >> In 1.3.4 there is a charstyle property "language()" which
> >> should be used for
> >> spellchecking, hyphenation and shortwords.
> > OK. I will look at it. There are essentially two things that need
> > to be solved for choosing an appropriate default for the user in
> > need of spell-checking, the first being the language that she
> > would use, and the second the character encoding that the words
> > would be entered in. From where things stand, it should be possible
> > to accommodate both, but I think that the first version of the
> > plugin will assume Unicode (UTF-8) for the character encoding. Are
> > there any issues, other than efficiency, with this?
> Scribus uses only Unicode internally. QStrings are UTF-16, but it's also
> easy to get a zero-terminated UTF-8 string.
> >> As an additionnal note, I think the default language for spellchecking
> >> should be the GUI language of the app.
> I dont support this.
I understand that language settings have to be set independently for both:
a. the GUI
b. Spellchecker / Hyphenator / Shortwords
All I say is one of these, preferably -a, sets the default (or better said
is a filler help) for -b if and only if the user doesn't file in anything
else in the language fields of -b. We do need a language in that field,
don't we? Only a matter of easiness and userfriendlines.
Another option here could be (should be?) to make it so clear to users that
there are 2 fields where language can be set that we put them in one single
place, side by side, in the Prefs dialog.
I aknowledge a German user using a German GUI interface could well set an
English text and would thus use En for -b. But at the same time, wouldn't in
the majority of cases a user set the GUI in its own language to work with
document in this same language? Answer is probably yes. Then, why not
simplify the lives or everyone and pick that one language at the same time?
The other option here would be to leave the language field for -b to "none"
or "undefined"... To me, this will more or less confuse quite a bit the
users or lead to errors on the first use. If we can avoid this, it would be
I understand your concern about those settings being independant from one
another. After all, the language setting for -b is meant to be part of
stylesheets. So we do need as much flexibility as possible here. But we do
want to make sure the app remains user friendly and easy to set up from the
I assume that in most case the user will first want to define the GUI
language and will then be able to browse the Prefs, understand them and make
his/her choice among the options.
> I will need more information about this. Is this information
> > available somewhere, e.g., as some Scribus preference setting.
> In Scribus the information flows from Document language -> Default
> language -> Text language
> It's best to use the locally marked language all the time.
> >> On top of that, once the char style are fully implemeted, the
> >> spellchecking could then by tributary to the language selected for a
> >> particular stylesheet. Could this be done on the fly through an
> >> entire document where many languages would be used and each would be
> >> spellchecked with the appropriate dictionary?
> > This is possible, but I am not so convinced about its utility. The
> > current version of the plugin has a settings tab that can be used to
> > select a different aspell dictionary (loosely speaking, different
> > language, but one language might have multiple dictionaries). Does
> > that suffice?
> We should use some standard language/country codes, then the user can
> attach any dictionary to a given code.
> >> Also, user has to make a language choice when a text is not set using
> >> stylesheets. This then calls for a dialog displaying the language it
> >> is set to and the ability to change it from within that dialog.
> If not otherwise set, the text will use the language of the default
> So every character/word* has a language attribute.
> So, should there be an "unknown" language, so that any words tagged with
> "unknown" are either ignored or checked against a user specified
"undefined" would be my choice here: "unknown" sounds unprecise to me in
that particular case where you'd want to actually act upon a word that you
perflectly know why you wouldn't want to spellcheck or hyphenate or
> *) This technically allows to have different languages in the same word.
> spellchecker should probably just check the first char of a word and
> that language for the whole word -- it's probably easier to put
> words in an exception dictionary than require that the user marks up
> of the word with the correct language.
> View this message in context:
> Sent from the Scribus mailing list archive at Nabble.com.
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the scribus