Abdelrazak Younes wrote:
> So coming back to the original point: we don't need this alternate
> language preference, do we? We only need to make the spellchecker to
> understand that some languages are varieties of others that's all. But
> at LyX core level, this should be transparent. Am I miss
On 01/18/2010 07:06 PM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Because you can't mark the word as "Old German"?
No. I can and need to mark the word as "Old German".
OK.
I mean... shouldn't we
create 2 different languages instead of adding complexity to the
spel
Abdelrazak Younes wrote:
> Because you can't mark the word as "Old German"?
No. I can and need to mark the word as "Old German".
> I mean... shouldn't we
> create 2 different languages instead of adding complexity to the
> spelling code?
We have two different languages, this is not the point.
On 01/18/2010 06:15 PM, Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
But then, the lyxrc.spellchecker_alt_lang would not work anymore, since
this has to be inserted in the tuple (instead of the code).
Is this thing really useful now, or is it a remnant of ispell code?
Jean-Marc Lasgouttes wrote:
> > But then, the lyxrc.spellchecker_alt_lang would not work anymore, since
> > this has to be inserted in the tuple (instead of the code).
>
> Is this thing really useful now, or is it a remnant of ispell code?
I think it gets useful again with the varieties feature.
Jürgen Spitzmüller writes:
>> Yes, indeed, this would make things much easier.
>
> But then, the lyxrc.spellchecker_alt_lang would not work anymore, since this
> has to be inserted in the tuple (instead of the code).
Is this thing really useful now, or is it a remnant of ispell code?
Commit any
Jürgen Spitzmüller wrote:
> > I am not sure why this tuple does not contain a Language* directly.
>
> Yes, indeed, this would make things much easier.
But then, the lyxrc.spellchecker_alt_lang would not work anymore, since this
has to be inserted in the tuple (instead of the code).
We could use
Jürgen Spitzmüller writes:
> I thought about this, but I think this is more error prone. Think
> someone uses the language code for something and is not aware of the
> variety (which is by no means standard, as opposed to the language
> tags, but only aspell convention, AFAICS).
OK then.
> In th
Jean-Marc Lasgouttes wrote:
> It is more complicated now :)
It needs to :-(
> You could also have taken the approach of fixing the parsing of the
> relevant code.
I thought about this, but I think this is more error prone. Think someone uses
the language code for something and is not aware of t
Jürgen Spitzmüller wrote:
> The patch is against branch.
Patch against trunk is attached.
Jürgen
Index: src/Language.cpp
===
--- src/Language.cpp (Revision 33079)
+++ src/Language.cpp (Arbeitskopie)
@@ -20,6 +20,7 @@
#include "sup
Jürgen Spitzmüller writes:
> Jean-Marc Lasgouttes wrote:
>> No objection in general, but did you check the uses of this de_DE entry
>> in our code, to make sure that we handle gracefully the de-alt form? Are
>> labels still translated on screen?
>
> No, they're not, thanks.
>
> Attached is a more
Jean-Marc Lasgouttes wrote:
> No objection in general, but did you check the uses of this de_DE entry
> in our code, to make sure that we handle gracefully the de-alt form? Are
> labels still translated on screen?
No, they're not, thanks.
Attached is a more sane approach that works and does not i
Jürgen Spitzmüller writes:
> For this, the "variety" tag needs to be set. The attached patch does this and
> corrects the entry for old German spelling. The patch is intended both for
> branch and trunk.
> -german german "German (old spelling)" false iso8859-15 de_DE ""
> +german
In order to support parallel spell checking of German old and new spelling
(something I need desperately), I had to implement support for aspell language
varieties.
A variety is, well, a variety of a given language for which a separate
dictionary exists. Aspell's naming convention is lang[_REGI
14 matches
Mail list logo
