On Thu, 2024-06-13 at 10:58 +0200, Pavel Sanda wrote:
> On Wed, Jun 12, 2024 at 07:09:19PM +0300, Udicoudco wrote:
> > As I see it, when show changes in output
> > is selected, the output is not even remotely close to the final
> > manuscript.
>
> Right, but that was not my point. What I mean is t
On Wed, Jun 12, 2024 at 07:09:19PM +0300, Udicoudco wrote:
> As I see it, when show changes in output
> is selected, the output is not even remotely close to the final
> manuscript.
Right, but that was not my point. What I mean is that I just had to submit to a
journal reviewers revised version of
On Wed, Jun 12, 2024 at 6:40 PM Pavel Sanda wrote:
>
> On Wed, Jun 12, 2024 at 01:11:23PM +0300, Udicoudco wrote:
> > Does this matter? i.e. do we hold strongly
> > backwards compatibility of the output of change track?
>
> Generally we do in between minor version. Here I am ambivalent. I think us
On Wed, Jun 12, 2024 at 01:11:23PM +0300, Udicoudco wrote:
> Does this matter? i.e. do we hold strongly
> backwards compatibility of the output of change track?
Generally we do in between minor version. Here I am ambivalent. I think users
should feel confident between switching 2.4.x minor version
On Wed, Jun 12, 2024 at 10:32 AM Pavel Sanda wrote:
>
> On Mon, Jun 10, 2024 at 12:19:18PM +, Udi Fogiel wrote:
> > commit a5749b9c1f5c5b42e6d6db7cd9f2aab16bc28f5b
> > Author: Udi Fogiel
> > Date: Mon Jun 10 15:19:08 2024 +0300
> >
> > Fix chang
On Mon, Jun 10, 2024 at 12:19:18PM +, Udi Fogiel wrote:
> commit a5749b9c1f5c5b42e6d6db7cd9f2aab16bc28f5b
> Author: Udi Fogiel
> Date: Mon Jun 10 15:19:08 2024 +0300
>
> Fix change tracking colors with RTL languages (#12923)
> ---
> src/LaTeXFeatures.cpp | 4 ++--
Op 25-05-2020 om 20:01 schreef Richard Kimberly Heck:
Certainly sounds like a bug. Can you file a report please?
Riki
Bug #11878
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 5/25/20 11:49 AM, Cor Blom wrote:
> Hi,
>
> Take the following, simple document:
>
> \documentclass[ngerman,british]{scrbook}
> \usepackage{fontspec}
> \usepackage{polyglossia}
> \setdefaultlanguage[variant=british]{english}
> \setotherlanguage{german}
>
> \begin{document}
>
> English
>
> \begin
Hi,
Take the following, simple document:
\documentclass[ngerman,british]{scrbook}
\usepackage{fontspec}
\usepackage{polyglossia}
\setdefaultlanguage[variant=british]{english}
\setotherlanguage{german}
\begin{document}
English
\begin{german}
Deutsch
\end{german}
Continue
\end{document}
Wh
On Mon, Mar 16, 2020 at 11:30:23AM -, Guenter Milde wrote:
> On 2020-03-14, Scott Kostyshak wrote:
>
> > When I run the ctests, sometimes the supported-languages tests fail.
> > After comparing the failing .tex file produced to when I export on the
> > command line
On 2020-03-14, Scott Kostyshak wrote:
> When I run the ctests, sometimes the supported-languages tests fail.
> After comparing the failing .tex file produced to when I export on the
> command line, it seems that the .tex files are slightly different. The
> difference that causes the f
Am Sat, 14 Mar 2020 16:29:07 -0400
schrieb Scott Kostyshak :
> When I run the ctests, sometimes the supported-languages tests fail.
> After comparing the failing .tex file produced to when I export on the
> command line, it seems that the .tex files are slightly different. The
> dif
When I run the ctests, sometimes the supported-languages tests fail.
After comparing the failing .tex file produced to when I export on the
command line, it seems that the .tex files are slightly different. The
difference that causes the failure seems to be the order of the
languages in the
Kornel Benko wrote:
> >> >> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
>
> >> >> > Please try the updated "supported-languages" tests.
>
> ...
>
> > I did not realize that supported-languages_polyglossia
> >> Please try the updated "supported-languages" tests.
> >
> > > 399 -
> > > DEFAULTOUTPUT_export/export/latex/languages/supported-languages_polyglossia-XeTeX_pdf4_systemF
> > > (Failed)
> >
> > > LaTeX.cpp (742): Log line: ! Package
Am Mittwoch, 4. September 2019, 20:29:04 CEST schrieb Guenter Milde:
> On 2019-09-04, Kornel Benko wrote:
> > Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
>
> >> Please try the updated "supported-languages" tests.
>
> > 399
:02 CEST schrieb Guenter Milde:
>> >> > Please try the updated "supported-languages" tests.
...
> I did not realize that supported-languages_polyglossia-XeTeX.lyx is a
> new file. When I was testing manually, I was testing with
> supported-languages_polyglossia.lyx. Now I can
On Wed, Sep 04, 2019 at 08:37:57PM -, Guenter Milde wrote:
> On 2019-09-04, Scott Kostyshak wrote:
> > On Wed, Sep 04, 2019 at 03:04:35PM +0200, Kornel Benko wrote:
> >> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
>
> >> > Please try
On 2019-09-04, Scott Kostyshak wrote:
> On Wed, Sep 04, 2019 at 03:04:35PM +0200, Kornel Benko wrote:
>> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
>> > Please try the updated "supported-languages" tests.
Here, I get
The followi
On 2019-09-04, Scott Kostyshak wrote:
> On Wed, Sep 04, 2019 at 12:02:02PM -, Guenter Milde wrote:
>> On 2019-09-04, Scott Kostyshak wrote:
>> > On Tue, Sep 03, 2019 at 09:23:54PM -, Guenter Milde wrote:
>> >> On 2019-09-03, Scott Kostyshak wrote:
>> >> > On Mon, Sep 02, 2019 at 10:01:13PM
On 2019-09-04, Kornel Benko wrote:
> Am Mittwoch, 4. September 2019, 12:02:02 CEST schrieb Guenter Milde:
>> Please try the updated "supported-languages" tests.
> 399 -
> DEFAULTOUTPUT_export/export/latex/languages/supported-languages_polyglossia-XeTe
> > This is OK for many use case, where browsers or OpenOffice automatically
> > substitute missing characters when displaying a text: The Noto fonts are
> > split into smaller files with glyphs of a specific script intended to be
> > used together.
> >
>
gt;
> However, in Xe- and LuaTeX, there is no such automatic replacement, as this
> can lead to inferiour typographical results (mis-match of type styles).
> This makes the Noto fonts unsuited for TeX.
> Hopefully, in future LuaTeX will offer to define substitution fonts, but for
r files with glyphs of a specific script intended to be
> used together.
>
> However, in Xe- and LuaTeX, there is no such automatic replacement, as this
> can lead to inferiour typographical results (mis-match of type styles).
> This makes the Noto fonts unsuited for TeX.
> Hopefully, in future LuaTeX will offer to define substitution fonts, but for
> now this would require every full stop to be written in a different language
> than the running Lao text :(
>
> Fortunately, DejaVu contains a large set of characters, including Lao.
>
> Please try the updated "supported-languages" tests.
I will try this when I get home.
Thanks,
Scott
signature.asc
Description: PGP signature
intended to be
used together.
However, in Xe- and LuaTeX, there is no such automatic replacement, as this
can lead to inferiour typographical results (mis-match of type styles).
This makes the Noto fonts unsuited for TeX.
Hopefully, in future LuaTeX will offer to define substitution fonts, but for
now this would require every full stop to be written in a different language
than the running Lao text :(
Fortunately, DejaVu contains a large set of characters, including Lao.
Please try the updated "supported-languages" tests.
Günter
Am Montag, den 15.04.2019, 10:01 -0700 schrieb Sergei Winitzki:
> Thank you Jürgen for a quick response! I have been using LyX since
> 1999 for every technical document I write, and I am glad to see that
> the project is going strong after 20 years.
Meanwhile, I also encountered that we already ha
Thank you Jürgen for a quick response! I have been using LyX since 1999 for
every technical document I write, and I am glad to see that the project is
going strong after 20 years.
Sergei
Am Mo., 15. Apr. 2019 um 03:00 Uhr schrieb Jürgen Spitzmüller :
> Am Sonntag, den 14.04.2019, 22:26 -0700 sch
Am Sonntag, den 14.04.2019, 22:26 -0700 schrieb Sergei Winitzki:
>
> "I hereby grant permission to license my contributions to LyX
> under the GNU General Public License, version 2 or later."
Thanks, Sergei. Patch is in (master).
Riki, this could also be backported.
Jürgen
signature.asc
Desc
; Listings.tex support is missing a few newer languages. This patch
> > adds them.
>
> Dear Sergei
>
> Many thanks for this contribution! There's a small glitch in it,
> though: you dropped "C" from languages_gui.
>
> Also, before we can commit, we need your exp
Am Donnerstag, den 11.04.2019, 19:12 -0700 schrieb Sergei Winitzki:
> Hi,
> Listings.tex support is missing a few newer languages. This patch
> adds them.
Dear Sergei
Many thanks for this contribution! There's a small glitch in it,
though: you dropped "C" from languages_g
Am Samstag, 13. April 2019, 15:54:03 CEST schrieb Guenter Milde:
> Thank you for testing and reporting
> (also for the helpfull logs in private mail).
>
> Günter
>
Confirmed that the /ja/ tests now pass :)
Kornel
signature.asc
Description: This is a digitally signed message part.
On 2019-04-13, Kornel Benko wrote:
> Am Freitag, 12. April 2019, 21:44:36 CEST schrieb Kornel Benko:
...
> That is 18 tests are failing, (not 164)
Mind, that this is after activation of a ~65 previously ignored tests for
Japanese with non-TeX fonts (.*_systemF)!
> ..., the remaining failures ar
Am Freitag, 12. April 2019, 21:44:36 CEST schrieb Kornel Benko:
> Am Freitag, 12. April 2019, 18:28:43 CEST schrieb Günter Milde:
> > commit 62f8b4fac126e1c0dc85107dac4852d725dc1cc9
> > Author: Günter Milde
> > Date: Fri Apr 12 18:34:06 2019 +0200
> >
> >
Hi,
Listings.tex support is missing a few newer languages. This patch adds them.
Regards,
Sergei
mychanges.diff
Description: Binary data
Am Samstag, den 21.04.2018, 19:43 -0400 schrieb Richard Kimberly Heck:
> This needs a layout format update, I would think.
But the languages file is unrelated to layouts.
Jürgen
>
> Riki
>
signature.asc
Description: This is a digitally signed message part
On 04/21/2018 09:48 AM, Juergen Spitzmueller wrote:
> commit 71f0dd3a7ff4c25e1339ed493605e88b25f2779a
> Author: Juergen Spitzmueller
> Date: Sat Apr 21 15:47:39 2018 +0200
>
> Add Provides tag to languages
>
> This allows to specify macros that are provid
Le 14/02/2018 à 14:51, Uwe Stöhr a écrit :
commit 1fb1b0a3f8429a12ce63b6daada1ac4ec4119889
Author: Uwe Stöhr
Date: Wed Feb 14 14:51:22 2018 +0100
UserGuide.lyx: document the removal of the pixmap cache for all languages
Dear Uwe,
Technically pixmap cache has not been removed yet from
Pavel Sanda wrote:
> Per stats on https://www.lyx.org/I18n-trunk it might be proper time to drop
> support for languages having less than %50 translation status.
>
> Those would be the winners: Russian, Danish, Greek, Serbian,
> Galician, Catalan, Romanian, Dutch.
I did it. P
Per stats on https://www.lyx.org/I18n-trunk it might be proper time to drop
support for languages having less %50 than translation status.
Those would be the winners: Russian, Danish, Greek, Serbian,
Galician, Catalan, Romanian, Dutch.
Any resistance?
Pavel
diff --git a/po/LINGUAS b/po/LINGUAS
to the body tag for XHTML export. This should take
care of much of what we need to do for RTL languages. It does not
take care of inline language changes, probably.
Actually, we force the text direction according to language.
Font::isVisibleRightToLeft gives this information. "Hebre
7; to the body tag for XHTML export. This should take
>> care of much of what we need to do for RTL languages. It does not
>> take care of inline language changes, probably.
>
> Actually, we force the text direction according to language.
> Font::isVisibleRightToLeft giv
Le 31/07/2016 à 08:53, Richard Heck a écrit :
commit 07dcb1c525435c6f22de4314ba31150c53502429
Author: Richard Heck
Date: Sun Jul 31 02:52:30 2016 -0400
Add 'dir="auto"' to the body tag for XHTML export. This should take
care of much of what we need to do for RT
2015-05-21 11:05 GMT+02:00 Jean-Marc Lasgouttes :
> It is in now. I also slightly updated the comments in lib/language and the
> README.localization file.
>
> The only remaining issue is that Arabic is shown as "Arabic (ArabTeX)". It
> would be nice if a native Arabic speaker could tell us whether
Le 20/05/2015 18:38, Kornel Benko a écrit :
Here is a much simpler patch that should also fix the sorting problem.
Is it better?
Definitely, yes :)
It is in now. I also slightly updated the comments in lib/language and
the README.localization file.
The only remaining issue is that Arabic
Am Mittwoch, 20. Mai 2015 um 18:19:08, schrieb Jean-Marc Lasgouttes
> Le 20/05/2015 15:19, Kornel Benko a écrit :
> > The sorting of languages is suboptimal. It was better in the original
> > version.
> >
> > For instance in Czech and Slovak the letters 'c&#
Le 20/05/2015 15:19, Kornel Benko a écrit :
The sorting of languages is suboptimal. It was better in the original version.
For instance in Czech and Slovak the letters 'c' and 'č' follows immediately.
In the Slovak GUI the sort in the patch moves 'č' nearly to t
Le 20/05/2015 15:15, Jürgen Spitzmüller a écrit :
Would it be possible to auto-generate po/LINGUAS from these
informations? So we only needed to update one file?
Yes, it would be possible with some python scripting. However, I am not
a python guy.
I understand that the GUI for the UI name d
>>
> >> That would make sense.
> >
> > I'll try that.
>
> Here is a new version that relies on a new tag HasGuiSupport. Now, if we
> add a new translation, if will be necessary to
> (1) update po/LINGUAS
> (2) update lib/languages
>
> Is this new ite
at would make sense.
>>>
>>
>> I'll try that.
>>
>
> Here is a new version that relies on a new tag HasGuiSupport. Now, if we
> add a new translation, if will be necessary to
> (1) update po/LINGUAS
> (2) update lib/languages
>
> Is this new iter
. Now, if we
add a new translation, if will be necessary to
(1) update po/LINGUAS
(2) update lib/languages
Is this new iteration more acceptable to everybody?
JMarc
>From 536589c04435b83db4ef44e48fcffc7426eab74a Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Thu, 7 May 2015
Am Dienstag, 12. Mai 2015 um 15:03:58, schrieb Jean-Marc Lasgouttes
> Le 12/05/2015 14:36, Jürgen Spitzmüller a écrit :
> > 2015-05-12 10:37 GMT+02:00 Jean-Marc Lasgouttes:
> >
> > Concerning the ordering of languages, seriously the current ordering
> > is ju
2015-05-12 15:03 GMT+02:00 Jean-Marc Lasgouttes:
> Le 12/05/2015 14:36, Jürgen Spitzmüller a écrit :
>
>> 2015-05-12 10:37 GMT+02:00 Jean-Marc Lasgouttes:
>>
>> Concerning the ordering of languages, seriously the current ordering
>> is just broken, and I thi
Le 12/05/2015 14:36, Jürgen Spitzmüller a écrit :
2015-05-12 10:37 GMT+02:00 Jean-Marc Lasgouttes:
Concerning the ordering of languages, seriously the current ordering
is just broken, and I think that ordering by GUIName is much more
useful for a human editor.
Hm, ordering by lyx
Le 11/05/2015 21:02, Stephan Witt a écrit :
Am 11.05.2015 um 17:18 schrieb Jürgen Spitzmüller :
This solution strikes me odd. The languages file is for document languages
support. Having it to be ordered for GUI language purposes just does not feel
right.
+1
I would rather create a
patch solves this problem. The way it is implemented is to decide that the
> first language that corresponds to a given .po file is the one that gets
> displayed. The languages file is therefore reorganized in order to be sorted
> by GuiName, which works weird.
>
> I wanted to avoid
2015-05-11 18:33 GMT+02:00 Jean-Marc Lasgouttes:
> Do we want separate file that needs to synchronized with the existing one?
>
I think it is cleaner that way, yes.
Jürgen
Note that the language is stored in the LyX file using names from lib/languages
already. I did not introduce a new dependency.
Do we want separate file that needs to synchronized with the existing one?
JMarc
PS: I am note sure that my patch compiles. I'll look at that tomorrow.
Le 11 mai
t; decide that the first language that corresponds to a given .po file is the
> one that gets displayed. The languages file is therefore reorganized in
> order to be sorted by GuiName, which works weird.
>
> I wanted to avoid having to create a new list of UI languages that would
> have t
one that gets displayed. The languages file is therefore reorganized
in order to be sorted by GuiName, which works weird.
I wanted to avoid having to create a new list of UI languages that would
have to be kept in sync when adding new languages. The only remaining
glitch is for Arabic, where the
Indeed. Let's forget about it, then.
JMarc.
Le 16 mars 2015 12:32:08 CET, "Jürgen Spitzmüller" a écrit :
>2015-03-15 18:47 GMT+01:00 Jean-Marc Lasgouttes:
>
>> We do not have a use case yet, but you commit that minus the part
>that
>> defines the set<> version.
>
>I am not really sure it makes s
2015-03-15 18:47 GMT+01:00 Jean-Marc Lasgouttes:
> We do not have a use case yet, but you commit that minus the part that
> defines the set<> version.
I am not really sure it makes sense if we just need VectorFromString, since
the change replaces push_back with insert in the template (since Set
Le 19/02/15 12:36, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
Note that if you used a set instead of a vector, you would not have to check
for duplicates.
Actually, I cannot do this, since the insertion order must be maintained.
Indeed.
Of course getVectorFrom string gives yo
Jean-Marc Lasgouttes wrote:
> Note that if you used a set instead of a vector, you would not have to check
> for duplicates.
Actually, I cannot do this, since the insertion order must be maintained.
> Of course getVectorFrom string gives you a vector, but it should be easy
> enough to create a g
On Wed, Feb 18, 2015 at 12:15 PM, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> If the double-quote glyph is missing in LHE, it should help to define a
>> default font encoding for \textquotedbl:
>>
>> \DeclareTextSymbolDefault{\textquotedbl}{T1}
>
> We use a different approach and output
Guenter Milde wrote:
> If the double-quote glyph is missing in LHE, it should help to define a
> default font encoding for \textquotedbl:
>
> \DeclareTextSymbolDefault{\textquotedbl}{T1}
We use a different approach and output something that works outside T1 (this
also affects some others glyph
On 2015-02-18, Scott Kostyshak wrote:
> On Sat, Jan 24, 2015 at 8:02 AM, Juergen Spitzmueller wrote:
>> commit 16c33b5f6e3fd5ff8f278542d6d12bc7c82ffb93
>> Author: Juergen Spitzmueller
>> Date: Sat Jan 24 14:02:16 2015 +0100
>> Move font encoding information
Scott Kostyshak wrote:
> Note that if I remove the line
> FontEncoding "LHE"
> from the Hebrew definition, the ctests pass (I am not suggesting this
> is the correct thing to do, I just wanted to provide you with this
> information).
Actually, this is probably correct. AFAIU hebrew babel load
Jean-Marc Lasgouttes wrote:
> Only a profiler can tell you that. Note that if you used a set instead
> of a vector, you would not have to check for duplicates. Of course
> getVectorFrom string gives you a vector, but it should be easy enough to
> create a getSetFromString or better to create a g
Le 18/02/2015 13:09, Jürgen Spitzmüller a écrit :
The attached patch implements such a check and fixes the problem. My only
concern is that the small vector of encodings is rebuild each time
font_encoding() is called (and thus each time
Paragraph::Private::latexSpecialChar is accessed). Is this s
rator fit = fencs.begin();
- for (; fit != fencs.end(); ++fit) {
-if (find(fontencs.begin(), fontencs.end(), *fit) == fontencs.end())
- fontencs.push_back(*fit);
- }
- }
+ // get main font encodings
+ vector fontencs = font_encodings();
// get font encodings of secondary languag
On Sat, Jan 24, 2015 at 8:02 AM, Juergen Spitzmueller wrote:
> commit 16c33b5f6e3fd5ff8f278542d6d12bc7c82ffb93
> Author: Juergen Spitzmueller
> Date: Sat Jan 24 14:02:16 2015 +0100
>
> Move font encoding information to languages.
>
After this commit I can no longer expor
On 04/21/2014 06:40 PM, Jean-Marc Lasgouttes wrote:
The warnings that remain after this patch are of two sorts:
* unused parameters in boost, like:
In file included from
../../../../master/boost/boost/smart_ptr/make_shared_array.hpp:15:
../../../../master/boost/boost/smart_ptr/detail/make_arra
^
JMarc
Le 24/03/2014 14:19, Jean-Marc Lasgouttes a écrit :
commit 8ac5f09c1783261018a107b54ce398733b8f97a4
Author: Jean-Marc Lasgouttes
Date: Fri Mar 21 12:24:47 2014 +0100
Do not store Languages objects in completion words lists
In the current code each paragra
Le 24/03/14 16:31, Richard Heck a écrit :
On 03/24/2014 11:26 AM, Jean-Marc Lasgouttes wrote:
Richard, I think we want that for 2.1.x eventually. In what branch do
you want me to commit it?
If it's intended for 2.1.x, then it should go into 2.1.1-staging. I think.
Done.
JMarc
On 03/24/2014 11:26 AM, Jean-Marc Lasgouttes wrote:
24/03/2014 14:19, Jean-Marc Lasgouttes:
commit 8ac5f09c1783261018a107b54ce398733b8f97a4
Author: Jean-Marc Lasgouttes
Date: Fri Mar 21 12:24:47 2014 +0100
Do not store Languages objects in completion words lists
In the current
24/03/2014 14:19, Jean-Marc Lasgouttes:
commit 8ac5f09c1783261018a107b54ce398733b8f97a4
Author: Jean-Marc Lasgouttes
Date: Fri Mar 21 12:24:47 2014 +0100
Do not store Languages objects in completion words lists
In the current code each paragraph contains a map, which means that it
21/03/2014 15:07, Jean-Marc Lasgouttes:
21/03/2014 12:54, Vincent van Ravesteijn:
Probably the Language class started out as a light-weight object. Now,
however, we store the complete layout translation in it, and thus every
Paragraph has a copy of this translation map, which indeed is quite
ove
Le 21/03/14 19:56, Georg Baum a écrit :
Vincent van Ravesteijn wrote:
On the other hand, I don't like using pointers instead. It feels fragile
to compare pointers. Why not just a "std::string language" as the key ?
Languages are compared by pointers at many other places,
Vincent van Ravesteijn wrote:
> On the other hand, I don't like using pointers instead. It feels fragile
> to compare pointers. Why not just a "std::string language" as the key ?
Languages are compared by pointers at many other places, which of course
assumes that the only
27;s a 13% reduction, not bad!
JMarc
>From f3278ee3038a78cf8ce8720833cc65a5ffe6eade Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Fri, 21 Mar 2014 12:24:47 +0100
Subject: [PATCH] Do not store Languages objects in completion words lists
In the current code each paragraph contains
d. It feels
fragile to compare pointers. Why not just a "std::string language" as
the key ?
This would also be safer if, at some point down the road, someone
decided we needed to be able to reload languages on the fly.
Richard
On Fri, Mar 21, 2014 at 12:33 PM, Jean-Marc Lasgouttes
wrote:
> Here is something I stumbled upon yesterday: each Paragraph object sores
> at least on copy of a Language object!
>
> I have not quantify the cost of this thing, but it may be useful to
> backport it to 2.1.x eventually.
>
> Looking a
ore Languages in completion work lists, but only
pointers
In the current code each paragraph contains a map, which means that it contains a full copy of the language
object. Since these objects contain translation tables nowadays, this
is a very bad idea.
This patch simply replaces the Language key
Am 19.07.2012 um 00:26 schrieb Jean-Marc Lasgouttes:
> Le 19/07/12 00:21, Jean-Marc Lasgouttes a écrit :
>> commit ed1515ef69d0381e9b0657cf1966f9d86e0cb25f
>> Author: Jean-Marc Lasgouttes
>> Date: Thu Jul 19 00:02:56 2012 +0200
>>
>> Read list of
Le 20/07/2012 15:52, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
Does this look better?
The best would be to try it :)
Ok, I will try once its in branch (I have set the building chain for packaging
2.0.x version).
I thought it would be better to test it before going to branch...
Anyw
Jean-Marc Lasgouttes wrote:
> Does this look better?
>
> The best would be to try it :)
Ok, I will try once its in branch (I have set the building chain for packaging
2.0.x version).
Pavel
ple
set CATALOGS at make install time (it would be weird because it is a
list of file names like "fr.gmo de.gmo..." not a list opf languages).
In practice, the contents of CATALOGS by taking the intersections of the
files mentionned in the po/LINGUAS _file_ and the ones in the LINGUAS
Jean-Marc Lasgouttes wrote:
> But tell us more about your distro. What does it do that could break
> everything?
I didn't say it would break everything :)
Under gentoo you can set system-wide or per package the language you want
to be installed. For example if I set that I'm interested only in fre
Le 20/07/2012 00:49, Pavel Sanda a écrit :
I use te variable CATALOGS which is built in po.m4 juste before generating
the po/Makefile. The variable cannot be subst'd using @CATALOGS@ in
Makefile.am, therefore it is easier to generate the file at configure time
(after all we already generate other
Am Donnerstag, 19. Juli 2012 um 23:36:01, schrieb Jean-Marc Lasgouttes
> Le 19/07/12 14:41, Kornel Benko a écrit :
> > > > In the new scheme, autotools install a file
> > lib/installed_translations that contains a list of installed languages
> > (the .gmo file
Am Freitag, 20. Juli 2012 um 00:49:47, schrieb Pavel Sanda
> Jean-Marc Lasgouttes wrote:
> >> How exactly is this list assembled? Just presence of .gmo in compiled tree
> >> is enough? This could break on linux installs where only subset of
> >> compiled
> >> translation is installed.
> >
> > I u
Jean-Marc Lasgouttes wrote:
>> How exactly is this list assembled? Just presence of .gmo in compiled tree
>> is enough? This could break on linux installs where only subset of
>> compiled
>> translation is installed.
>
> I use te variable CATALOGS which is built in po.m4 juste before generating
>
Le 19/07/12 21:17, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
In the new scheme, autotools install a file
lib/installed_translations that contains a list of installed languages
(the .gmo files that got installed). This file is read
How exactly is this list assembled? Just
Le 19/07/12 14:41, Kornel Benko a écrit :
> > In the new scheme, autotools install a file
lib/installed_translations that contains a list of installed languages
(the .gmo files that got installed). This file is read
How should automake reflect changes in the po-files? As I unde
Le 19/07/12 12:09, Kornel Benko a écrit :
Counting languages I wonder why I have 36 languages and here are only 32
languages listed?
Do we have to account for the number of translated strings?
Yes, we only take those which are green or orange on the status web page
(described in the file
Jean-Marc Lasgouttes wrote:
>> In the new scheme, autotools install a file
>> lib/installed_translations that contains a list of installed languages
>> (the .gmo files that got installed). This file is read
How exactly is this list assembled? Just presence of .gmo i
> Read list of translated languages from a file
> >
> > The previous scheme of loading all possible translations and checking
> > whether the work
> > is a bit too much "brute force" and causes problems on Mac OS X
> > (documents loaded
> >
> Read list of translated languages from a file
> >
> > The previous scheme of loading all possible translations and checking
> > whether the work
> > is a bit too much "brute force" and causes problems on Mac OS X
> > (documents loaded
> >
Le 19/07/12 00:21, Jean-Marc Lasgouttes a écrit :
commit ed1515ef69d0381e9b0657cf1966f9d86e0cb25f
Author: Jean-Marc Lasgouttes
Date: Thu Jul 19 00:02:56 2012 +0200
Read list of translated languages from a file
The previous scheme of loading all possible translations and checking
Am 08.06.2012 08:34, schrieb Jürgen Spitzmüller:
Hardcoding those languages is bad. Can't you just check if the
language has no babel name but a polyglossia name?
You are right. The list of languages only supported by polyglissia will
grow. I'll have a look when I'm
1 - 100 of 300 matches
Mail list logo
