How is the call to iconv implemented? On the application level, the
interface is probably not flexible enough; it is easy to ignore
non-convertible characters, but they are just removed from the output.
The C library interface is probably richer. Is it possible to convert text
word by word, fi
2014-04-10 1:02 GMT+02:00 Cyrille Artho :
> I think we have to use Unicode for all the given operations and (a) either
> risk a mismatch for each word that is not learned/ignored, or (b)
> up-convert words in the dictionary before they are matched. The latter
> solution implies that the dictionary
Vincent van Ravesteijn wrote:
> Vincent van Ravesteijn schreef op 9-4-2014 21:19:
>>
>> Pavel decided that the danish translation was on purpose, so I let him
>> verify also the layouttranslations file.
>
> I checked it myself now, and commit 8dd5a6e24 indeed explicitly changes
> multiple instanc
Vincent van Ravesteijn wrote:
> Pavel Sanda schreef op 12-3-2014 8:41:
>> commit 9f815ae033db1d5611d57293d82b89d572bb59a0
>> Author: Pavel Sanda
>> Date: Wed Mar 12 00:41:18 2014 -0700
>>
>> * ko.po : update from Dal Ho Park.
>
>
> I appreciate the effort for the Korean translation, but ple
Georg Baum wrote:
> IMHO all these entries do still need an explicit OK from a native
> speaker, but maybe I am misunderstanding something. Could you please explain
> how you interpret the review file?
My feeling was that starting to track every and each word movement is
overengineering, though
Usually given names are not in a language dictionary, although many
(translation) services have separate dictionaries for proper/given names.
We have two problems here:
(1) Language: I think most users are OK with proper names not being
accepted by the spell checker (before learning them). How
Am 09.04.2014 um 11:12 schrieb Jürgen Spitzmüller :
> 2014-04-09 10:59 GMT+02:00 Stephan Witt :
>
> That's a good example. So, my parents are from Hungarian and named me István.
> Let's assume the á isn't valid in german iso encoding. Then
> * I can change my name to Stephan - to avoid to spell m
Uwe Stöhr wrote:
> Well, we only release a major version ever 2 - 3 years. So we should take
> the time to bring it to a shape that we can advertise it. For example if
> there is e.g. an issue with the installation, press people don't give a
> program a good review. The same is with incomplete tra
2014-04-09 22:04 GMT+02:00 Georg Baum:
> "Chart" => "Diagramm"
> "Graph[[mathematical]]" => "Graph"
>
Makes sense. Got for it.
Jürgen
Vincent van Ravesteijn schreef op 9-4-2014 21:19:
Pavel decided that the danish translation was on purpose, so I let him
verify also the layouttranslations file.
I checked it myself now, and commit 8dd5a6e24 indeed explicitly changes
multiple instances of "Notat" to "Note", so it must be don
Pavel Sanda wrote:
> commit 169858d8e041e540b1e54b1131b929d6ff63b9e5
> Author: Pavel Sanda
> Date: Tue Apr 8 20:29:21 2014 -0700
>
> * layouttranslations.review - de seems to be updated at 050c768eef.
>
> diff --git a/lib/layouttranslations.review b/lib/layouttranslations.review
> index 4
Georg Baum schreef op 9-4-2014 21:14:
Vincent van Ravesteijn wrote:
Vincent van Ravesteijn schreef op 9-4-2014 20:33:
When running "make ../lib/layouttranslations" the "Note" string of the
Danish translation was not updated in the layouttranslations file.
because da.po translates "Note" to "N
Vincent van Ravesteijn wrote:
> Vincent van Ravesteijn schreef op 9-4-2014 20:33:
>> When running "make ../lib/layouttranslations" the "Note" string of the
>> Danish translation was not updated in the layouttranslations file.
because da.po translates "Note" to "Note".
>> After deleting the file
I propose the following:
Disable this feature for the 2.1 release. If you just comment out the
language entry, Jamil can easily enable it again on his side (without
recompiling) and help us testing and finishing the support for this
language.
I think this is a reasonable compromise.
I
Pavel Sanda schreef op 9-4-2014 5:51:
Vincent van Ravesteijn wrote:
Dear translators,
Vincent, most of the string in nl section seem to be translated,
except of Listings - can you check?
layouttranslations.review:
nl: "Acknowledgement", "Case", "Chart", (same translation as "Graph") "Claim",
Jürgen Spitzmüller wrote:
> 2014-04-09 9:52 GMT+02:00 Jean-Marc Lasgouttes :
>
>> I think the lyxerr message could be rewritten to be at least useful. Who
>> found a use for the use hex dump anyways?
>>
>
> Agreed.
Me too. I think this output is still unchanged from the time when we had
bugs i
Pavel Sanda schreef op 9-4-2014 6:00:
commit 992ec33e421546a741a6e475cf2a9f4bbcc3f1ef
Author: Pavel Sanda
Date: Tue Apr 8 21:00:21 2014 -0700
* layouttranslations.review - da - Note eems to be correct according to
9a3ba796d8f.
diff --git a/lib/layouttranslations.review b/lib/layouttran
Stephan Witt wrote:
> Am 08.04.2014 um 22:30 schrieb Georg Baum
>
>> No, the small w is not the workaround. The workaround is to display the
>> LaTeX command (e.g. "\omega") in red if the true symbol cannot be
>> displayed.
>
> How should this be forced? I cannot find the code for it.
Line 223
Vincent van Ravesteijn schreef op 9-4-2014 20:33:
When running "make ../lib/layouttranslations" the "Note" string of the
Danish translation was not updated in the layouttranslations file.
After deleting the file and rerunning the command, it was updated.
This seems like a bug.
Vincent
Also t
When running "make ../lib/layouttranslations" the "Note" string of the
Danish translation was not updated in the layouttranslations file.
After deleting the file and rerunning the command, it was updated.
This seems like a bug.
Vincent
Pavel Sanda schreef op 12-3-2014 8:41:
commit 9f815ae033db1d5611d57293d82b89d572bb59a0
Author: Pavel Sanda
Date: Wed Mar 12 00:41:18 2014 -0700
* ko.po : update from Dal Ho Park.
I appreciate the effort for the Korean translation, but please note that
it is still disabled.
Does the
> On Apr 9, 2014, at 12:37 PM, Richard Heck wrote:
>
> On 04/09/2014 07:58 AM, Sean Burke wrote:
>>> On Apr 9, 2014, at 4:20 AM, Jean-Marc Lasgouttes wrote:
>>>
>>> 08/04/2014 20:55, Sean Patrick Burke:
I wonder if a better approach would be to write a converter-agnostic
script?
>
On Mon, Apr 7, 2014 at 8:24 AM, stefano franchi
wrote:
> I haven't done any concrete coding in the area, but my favorite strategy
> for the Word-->LyX step would tend to lean toward a direct parsing of the
> XML format produced either by Word (the docx format) or by
> {Open|Libre}Office (the odt
On 04/09/2014 07:58 AM, Sean Burke wrote:
On Apr 9, 2014, at 4:20 AM, Jean-Marc Lasgouttes wrote:
08/04/2014 20:55, Sean Patrick Burke:
I wonder if a better approach would be to write a converter-agnostic script?
So for example, the script searches for the usual converters - soffice,
textuti
José Matos wrote:
> On Wednesday 09 April 2014 08:34:29 Pavel Sanda wrote:
> > Please check whether 64e2b3608 is correct I changed other math strings
> > accordingly.
> >
> > Pavel
>
> Yes, it is. Thank you. :-)
Time to ask Susana for the rest of pt.po :)
P
On Wednesday 09 April 2014 08:34:29 Pavel Sanda wrote:
> Please check whether 64e2b3608 is correct I changed other math strings
> accordingly.
>
> Pavel
Yes, it is. Thank you. :-)
--
José Abílio
José Matos wrote:
> With the following patch both Portuguese and Brazilian Portuguese are
> reviewed and complete.
Please check whether 64e2b3608 is correct I changed other math strings
accordingly.
Pavel
On Wednesday 09 April 2014 11:14:15 Vincent van Ravesteijn wrote:
> On Wed, Apr 9, 2014 at 6:34 AM, Pavel Sanda wrote:
> > commit 7b48843c778a8f9c97bc676d01ad549579014060
> > Author: Pavel Sanda
> > Date: Tue Apr 8 21:33:13 2014 -0700
> >
> > * layouttranslations.review - review of all lang
Vincent van Ravesteijn wrote:
> Kornel has reviewed Slovak, so this can be removed.
Yep, overlook on my side. P
> On Apr 9, 2014, at 4:20 AM, Jean-Marc Lasgouttes wrote:
>
> 08/04/2014 20:55, Sean Patrick Burke:
>> I wonder if a better approach would be to write a converter-agnostic script?
>>
>> So for example, the script searches for the usual converters - soffice,
>> textutil, writer2latex, rtf2latex an
09/04/2014 12:47, Vincent van Ravesteijn:
Urdu uses the same script, so the same arabic_table can be reused,
just as the table is also used for Farsi.
Some specific Urdu letters are not implemented in this table, but it
is almost trivial to fix that.
OK, so maybe is it possible to do something
On Wed, Apr 9, 2014 at 12:33 PM, Jean-Marc Lasgouttes
wrote:
> 09/04/2014 11:06, Vincent van Ravesteijn:
>
>> Am I misunderstanding or will we have a 90% solution if we just assume
>> that the script is the same as arabic ? Then there are only a few
>> exceptions that might need special attention
09/04/2014 11:06, Vincent van Ravesteijn:
Am I misunderstanding or will we have a 90% solution if we just assume
that the script is the same as arabic ? Then there are only a few
exceptions that might need special attention ?
The problem is to have the equivalent of Encodings::transformChar (an
2014-04-09 10:57 GMT+02:00 Vincent van Ravesteijn:
> Yes. Thanks.
>
Done.
Jürgen
>
> Vincent
>
On Wed, Apr 9, 2014 at 6:34 AM, Pavel Sanda wrote:
> commit 7b48843c778a8f9c97bc676d01ad549579014060
> Author: Pavel Sanda
> Date: Tue Apr 8 21:33:13 2014 -0700
>
> * layouttranslations.review - review of all langs.
>
> This list is hard to get exactly, but tried my best according
>
2014-04-09 10:59 GMT+02:00 Stephan Witt :
>
> That's a good example. So, my parents are from Hungarian and named me
> István.
> Let's assume the á isn't valid in german iso encoding. Then
> * I can change my name to Stephan - to avoid to spell my name on every
> formal occasion
> * if I don't like
On Wed, Apr 9, 2014 at 10:57 AM, Jean-Marc Lasgouttes
wrote:
> 08/04/2014 23:56, Uwe Stöhr:
>
>> So as Jamil stated, the output is correct. What is not working yet
>> are the special ligatures in the font within LyX. As said Jamil
>> volunteered to get that fixed soon. I am not the expert but JMar
On Tue, Apr 8, 2014 at 11:19 AM, Vincent van Ravesteijn wrote:
> At the moment I've a few issues left that I think need some consideration.
>
> - As it seems that nearly all communications with the translators are
> going solely by private mail by Uwe, and as Uwe apparently left
> without further
Am 09.04.2014 um 08:53 schrieb Jürgen Spitzmüller :
> 2014-04-09 8:40 GMT+02:00 Stephan Witt :
> Can you provide an example, please? If the word cannot be converted to
> Hunspell dictionary encoding
> the dictionary is broken or the language is not correct, isn't it?
>
> Depends on how you defin
On Wed, Apr 9, 2014 at 10:57 AM, Jürgen Spitzmüller wrote:
> 2014-04-09 10:55 GMT+02:00 Vincent van Ravesteijn:
>
>> Ok, I (or someone else) will proceed then. Thanks for the understanding.
>
>
> I can do that. I will add a comment. OK?
>
> Jürgen
>
>>
>>
>> Vincent
>
>
Yes. Thanks.
Vincent
2014-04-09 10:55 GMT+02:00 Vincent van Ravesteijn:
> Ok, I (or someone else) will proceed then. Thanks for the understanding.
>
I can do that. I will add a comment. OK?
Jürgen
>
> Vincent
>
08/04/2014 23:56, Uwe Stöhr:
So as Jamil stated, the output is correct. What is not working yet
are the special ligatures in the font within LyX. As said Jamil
volunteered to get that fixed soon. I am not the expert but JMarc
said this could probably be done in the 2.1.x cycle.
I have to retrac
2014-04-09 10:49 GMT+02:00 Vincent van Ravesteijn:
> I don't understand why you keep saying that only the RTL flag is
> missing, while we have made it clear to you that there is so much more
> missing. It's a bit shocking you didn't even know that arabic
> characters change shape depending on whet
On Wed, Apr 9, 2014 at 10:44 AM, Jürgen Spitzmüller wrote:
> 2014-04-09 10:09 GMT+02:00 Vincent van Ravesteijn:
>
>> I want to propose to disable this feature for now. Then, as soon as
>> possible we replace the error by a warning when we detect a BibTeX
>> error stating that in the future this wi
On Tue, Apr 8, 2014 at 11:56 PM, Uwe Stöhr wrote:
> Am 04.04.2014 08:25, schrieb Vincent van Ravesteijn:
>
>
>> Sorry, but there is nothing about Urdu that we support (except an
>> entry in the languages file),
>
>
> And with this we support hyphenations, automatic translations of words like
> "fi
09/04/2014 10:44, Jürgen Spitzmüller:
I am fine with that: disable the feature and think how to resolve the
problems with it within the next cycle (I think there are alternatives
to what you propose, but it needs time and testing).
Having support for warnings would be great in general.
JMarc
2014-04-09 10:09 GMT+02:00 Vincent van Ravesteijn:
> I want to propose to disable this feature for now. Then, as soon as
> possible we replace the error by a warning when we detect a BibTeX
> error stating that in the future this will lead to an error.
>
> Then, if we succeed to quickly release th
2014-04-09 9:52 GMT+02:00 Jean-Marc Lasgouttes :
> I think the lyxerr message could be rewritten to be at least useful. Who
> found a use for the use hex dump anyways?
>
Agreed.
Jürgen
>
> JMarc
>
>
08/04/2014 20:55, Sean Patrick Burke:
I wonder if a better approach would be to write a converter-agnostic script?
So for example, the script searches for the usual converters - soffice,
textutil, writer2latex, rtf2latex and then cobbles together a chain of formats
to get to lyx?
Did you hav
09/04/2014 10:09, Vincent van Ravesteijn:
I want to propose to disable this feature for now. Then, as soon as
possible we replace the error by a warning when we detect a BibTeX
error stating that in the future this will lead to an error.
Then, if we succeed to quickly release the next major rele
On Tue, Apr 8, 2014 at 11:56 AM, Jürgen Spitzmüller wrote:
> 2014-04-08 11:19 GMT+02:00 Vincent van Ravesteijn:
>
>> - Documents not compiling anymore because of BibTeX errors. We already
>> received a lot of reports and this can prohibit people from updating.
>
>
> You can still decide to disable
On Tue, Apr 8, 2014 at 10:20 PM, Georg Baum
wrote:
> Jürgen Spitzmüller wrote:
>
>> 2014-04-08 11:19 GMT+02:00 Vincent van Ravesteijn:
>>
>> You can still decide to disable this feature (probably as easy as removing
>> BIBTEX_ERROR from the ERROR declaration in LaTeX.h:142). Fiddling with the
>> f
09/04/2014 00:35, Uwe Stöhr:
I started this thread for various reasons, one of the main reason is
that I miss a concept for LyX and the 2.1 release. What is our plan
for advertisement, when do we think it is a good time to release, who
of the press people do we ant to inform, what do we think is
To slightly detail the response. The work-around is already in rc1 and
that's probably the small w that is observed. There will be no change
between 2.1.0 final and rc1.
>
> Why are you talking about the small w? The Omega problem is with unicode
> 0x00ad.
> That's the big omega. I'
09/04/2014 08:14, Jürgen Spitzmüller:
2014-04-08 22:42 GMT+02:00 Georg Baum:
The change in src/support/unicode.cpp is problematic: It disables
all error
handling, not only the lyxerr output. Also, if you now throw an
exception
there, you need to make sure that all callers can
55 matches
Mail list logo
