Re: Translations of Math environments in LyX output for LyX 2.2

[Georg Baum]

Am 06.04.2016 um 03:39 schrieb Georger Araujo:

Hi Julio,
I don't really know the use cases in LyX/LaTeX.

What I do know is that, in pt_BR, a graphical representation of a data set is usually called a 
"gráfico"; e.g. a pie chart is a "gráfico de pizza".
On the other hand, a graphical representation that portrays the structure of an idea or concept or 
entity, and/or the links between them, is usually called a "diagrama"; e.g. a UML diagram 
is a "diagrama UML".

It's not wrong (but it IS a bit unusual) to call a barplot a "diagrama de barras" in pt_BR; that's 
what we were doing before it was clarified that "Graph" refers to a set of vertices and edges. That 
said, a barplot is usually called a "gráfico de barras" around here.


Actually I am not 100% sure about the use case. I had a look at other 
translations, and many of them (I guess almost all that have a smilar 
word in the language available) use a word similar to diagram. For 
spanish I guess it is probably best not to change from "Diagrama" which 
we have in 2.1 if we are not 100% sure that the new translation is more 
correct, in order to minimze surprises.



Georg

Re: Translations of Math environments in LyX output for LyX 2.2

[Georg Baum]

Am 05.04.2016 um 22:47 schrieb Pedro Neves:

Hi Georg:

On 05-04-2016 20:48, Georg Baum wrote:



In proper Spanish the translation of Tableau(x) would be Tablero(s). But
I really cannot find a Spanish translation for Tableau(x) in Latex using
Google. Furthermore, the Portuguese and Italian translations use
Tableau(x). Nevertheless, I have never seen Tableau(x) used in a Spanish
document in my life.

That's it. Regards.



Regarding "Tableau(x)", I'm not sure what it means. I though we were
referring to tables, but obviously, we aren't. I've found one Wikipedia
entry in Portuguese that mentions it
(https://pt.wikipedia.org/wiki/M%C3%A9todo_dos_Tableaux), so I guess we
might leave "Tableau(x)" also in pt_PT.


It is from optimality therory in linguistics: 
https://en.wikipedia.org/wiki/Optimality_theory


I will add a [[linguistics]] context marker for LyX 2.3, so that this is 
clear.



I'd like to translate Graph to Grafo in all three languages. Compared
to 2.1 this would be a change for spanish, and no change for the two
portuguese variants. Are there any objections?

Concerning Chart I don't know if we should keep Diagrama (it is
currently the same in all three languages), or do what Geoger wanted
to do and use Gráfico. My guess would be that the translation of this
term would probably be identical for the two portuguese variants, and
maybe even for all three languages.



Ok. I didn't realize we were talking about graphs in the mathematical
sense (i.e., as in graph theory). In that case, the correct word in
pt_PT is indeed "grafo" (see for instance:
https://pt.wikipedia.org/wiki/Grafo_orientado).

Sorry for the confusion...


Thanks for your help. Since all agree I'll change all thre languages to 
Grafo for Graph.



Georg

Re: Translations of Math environments in LyX output for LyX 2.2

[Georg Baum]

Am 06.04.2016 um 00:56 schrieb Uwe Stöhr:

Am 05.04.2016 um 08:46 schrieb Georg Baum:


Which strings? These might require a remerge of the other languages as
well


I remerged all po files yesterday because I noticed that e.g. the
longtable name change was not present in fr.po, de.po etc.
In pt_BR.po I saw that too but after I committed Georger's changes, I
saw that actually nothing was changed because this was already in -
strange.


Concerning the layouttranslations file i cannot see a difference to the
file in today's git. Maybe Georg already included your updates.


I did that indeed, and the .po file was also already submitted. Uwe, at
some time we need to figure out why your .po file submits change the
line endings in some cases.


I don't think that this is me. I receive the different po-files from
different people using different editors. I only add them to my git
tree, check if they are compilable and then commit. In the vast majority
I commit without any change to the files. Up to now I was not aware that
there are problems with scripts. I do this for years now and Richard is
on Linux preparing there the .x releases.


git says that it is you: The broken line endings are always introduced 
with a remerge .po file commit from you, the last one was 
http://www.lyx.org/trac/changeset/aaf2cc5dbe7321334e34000eacb7edba8755f0f2/lyxgit.



This causes trouble with our python scripts
which parse them, they always have to be in unix form (\n, not \r\n).
Until we found out the reason please look at the diffe before
submitting, and if the .po file has windows line endings please change
them to unix line endings (could be done e. g. by notepad2).


But how could I check if there are the wrong line endings?


With any good text editor. I use notepad2 when I am on windows, IIRC it 
has that in the file menu. Also, the diff functionality in your git 
client has probably a setting to ignore white space and line ending 
differences or not. If you set that to show all whitespace and line 
ending differences you'll see these changes befor commit in the diff. 
The diff in trac does unfortunately not show them.



Why can the
python scripts not handle both line ending types? Here the scripts can
handle also Unix line endings so it should be possible to have the
opposite on Linux too and obviously it works at least for Richard.
Richard, do you have an idea?


I agree that the python scripts should work with both line endings. It 
is simply a bug that they cannot cope with windows iine endings on 
windows. Unfortunately up to now nobody had the time to investigate 
this. We have four combinations that must work:


windows line endings on windows
windows line endings on unix
unix line endings on windows
unix line endings on unix

The reason for this is that you might be on windows, and receive a .po 
file from a unix user that you want to commit, and vice versa. Until the 
scripts are fixed please don't do a remerge, since this would create 
extra work for others (and a remerge during string freeze is 
questionable anyway, since this would mean that something wnet wrong 
when the strings were frozen, and this would need discussion).


If you commit .po file updates from translators please ensure that they 
have unix line endings. This can be done with any decent editor like I 
wrote above. Unfortunately the '\r' characters in the middle of a line 
that are created by a remerge cannot be fixed that easily.



Georg

Re: Translations of Math environments in LyX output for LyX 2.2

[Georg Baum]

Hi Julio,

thank you very much for your review. Spanish was not on the list of the 
languages needing a review, but you found an important issue. I made a 
mistake for the review of the portuguese translations (see below).



Am 05.04.2016 um 14:41 schrieb Julio Rojas:

Dear Georg,

In Spanish it appears:
"Graph[[mathematical]]" "Gráfico"
"List of Graphs[[mathematical]]" "Índice de Gráficos"

Is this for plots or for graphs? If the former, then the translation is
correct, but if the latter the correct translation will be "Grafo" for
singular and "Grafos" for plural.


It is not for plots (there is chart for those). It is for graphs in the 
mathematical sense (e.g. as in graph theory).



I believe the following has already been discussed:
"List of Tableaux" "Índice de Tableaux"
"Tableau" "Tableau"


Yes.


In proper Spanish the translation of Tableau(x) would be Tablero(s). But
I really cannot find a Spanish translation for Tableau(x) in Latex using
Google. Furthermore, the Portuguese and Italian translations use
Tableau(x). Nevertheless, I have never seen Tableau(x) used in a Spanish
document in my life.

That's it. Regards.


Again, thank you very much. Now, lets move on to my mistake. If we take 
history into account, we can see it:


The initial translations in LyX 2.0:
en es   pt_PTpt_BR
Graph  Gráfico  Gráfico  Gráfico

This changed in 2.1, after we added the [[mathematical]] suffix:
en es   pt_PT  pt_BR
Graph  Gráfico  Grafo  Grafo

Currently we have in 2.2:
en es   pt_PTpt_BR
Graph  Gráfico  Gráfico  Gráfico

My mistake was that I blindly transferred the translations from the .po 
files to lib/layouttranslations. I did not realize that the portuguese 
translation for Graph had not been updated for LyX 2.1 to match the one 
in lib/layouttranslations.


I apologize for insisting on the wrong version to Pedro and Geoger. I'd 
like to translate Graph to Grafo in all three languages. Compared to 2.1 
this would be a change for spanish, and no change for the two portuguese 
variants. Are there any objections?


Concerning Chart I don't know if we should keep Diagrama (it is 
currently the same in all three languages), or do what Geoger wanted to 
do and use Gráfico. My guess would be that the translation of this term 
would probably be identical for the two portuguese variants, and maybe 
even for all three languages.



Georg

Re: Translations of Math environments in LyX output for LyX 2.2

[Georg Baum]

Am 05.04.2016 um 03:21 schrieb Georger Araujo:

Em Segunda-feira, 4 de Abril de 2016 20:26, Uwe Stöhr  
escreveu:

Am 03.04.2016 um 15:07 schrieb Georger Araujo:

I have reviewed the pt_BR translations. The updated pt_BR.po file, along with 
layouttranslations, is attached.



Many thanks, the po-file is in. Note that there are some new
untranslated strings that just showed up today. Could you please have a
look?


Which strings? These might require a remerge of the other languages as well.



Concerning the layouttranslations file i cannot see a difference to the
file in today's git. Maybe Georg already included your updates.


I did that indeed, and the .po file was also already submitted. Uwe, at 
some time we need to figure out why your .po file submits change the 
line endings in some cases. This causes trouble with our python scripts 
which parse them, they always have to be in unix form (\n, not \r\n). 
Until we found out the reason please look at the diffe before 
submitting, and if the .po file has windows line endings please change 
them to unix line endings (could be done e. g. by notepad2).




best regards
Uwe



Hi Uwe,
I have just translated the latest untranslated strings. The po-file is attached.
By the way, the attached po-file includes the changes Georg suggested ("Chart" -> "Diagrama", 
"List of Charts" -> "Lista de Diagramas").


Thank you very much, this is now in as well (both the .po file and 
layouttranslations).



Georg

Translations of Math environments in LyX output for LyX 2.2

[Georg Baum]

Dear translators,

Since LyX 2.0, LyX has automatic translation of math environments strings
(and some floats) to the localized form. For example "Exercise" becomes
"Aufgabe" in the output of the documents with language set to german.

In the attached file you find a list of translations which will appear in
exported documents, not only in the GUI. These translations will be 
fixed for

the 2.2.x release cycle, since the contents of documents must not change
between minor releases. It is still possible to add or change these
translations in .po files as usual, but these updates will only be used 
for the

GUI and not appear in the file lib/layouttranslations, which is used for the
exported translations.

For some languages these translations have been reviewed prior to the 
LyX 2.0
release but have changed during the LyX 2.1 and 2.2 development or new 
strings
have been added. For the other languages the complete file need to be 
reviewed.


The attached file contains all translations for all languages. Please
ensure that they are correctly translated. Make any needed update in the .po
files as usual, or send them to me. The lib/layouttranslations file will 
be regenerated

automatically from the .po files before the final 2.2.0 release.

Please send your reviews until April, 4th. I am sorry for the short time 
frame and apologize that we forgot to send the request earlier.



## Overview of strings to be reviewed:

The following languages need to be reviewed completely (see attached file)

 Arabic (ar), Bulgarian (bg), Catalan (ca), Greek (el), Galician (gl),
 Korean (ko), Slovene (sl), Turkish (tr)


The following translations need to be review for the languages Basque 
(eu), Finnish (fi), Hungarian hu, Indonesian (id), Romanian (ro) and 
Serbian (sr):


 "Property"
 "Solution",
 "Listing",
 "Listings"

These were newly introduced in LyX 2.1 and have not yet been reviewed.


In addition, the following languages have specific strings that need to be
reviewed. These translations did change from LyX 2.1:

Japanese (ja):
"Note"
Norwegian (Bokmaal) (nb):
"List of Listings"
Dutch (nl):
"List of Listings"
Portuguese (Brazil) (pt_BR)
"Chart",
"Conjecture",
"Graph",
"List of Charts",
"List of Graphs",
"List of Tableaux",
"Listings",
"Question",
"Summary"
Portuguese (pt_PT)
"Graph",
"Question"
Russian (ru)
"Acknowledgement"


Kind regards,

Georg

PS: This message was sent to the documentation list and the translators 
of the affected languages as bcc.
# This file has been automatically generated by po/lyx_pot.py.
# PLEASE MODIFY ONLY THE LAGUAGES HAVING NO .po FILE! If you want to regenerate
# this file from the translations, run `make ../lib/layouttranslations' in po.
# Python polib library is needed for building the output file.
#
# This file should remain fixed during minor LyX releases.
# For more comments see README.localization file.

Translation ar
"Acknowledgement" "اعتراف بالجميل"
"Algorithm" "الخوارزم"
"Assumption" "فرضية"
"Axiom" "مُسلّمة"
"Case" "حالة"
"Chart" "جدول بياني"
"Claim" "متطلب"
"Conclusion" "استنتاج"
"Condition" "شرط"
"Conjecture" "حدس"
"Corollary" "لازمة"
"Criterion" "معيار"
"Definition" "تعريف"
"Example" "مثال"
"Exercise" "تمرين"
"Fact" "حقيقة"
"Graph[[mathematical]]" "رسم بياني"
"Lemma" "قضية مساعدة"
"List of Algorithms" "قائمة الخوارزميات"
"List of Charts" "قائمة الجداول البيانية"
"List of Graphs[[mathematical]]" "قائمة الرسوم البيانية"
"List of Schemes" "قائمة المخططات"
"List of Tableaux" "قائمة الجداول"
"Listing" "عمل قوائم"
"Listings[[List of Listings]]" "القوائم"
"Notation" "تدوين"
"Note" "ملاحظة"
"Problem" "مشكلة"
"Proof" "برهان"
"Property" "خاصية"
"Proposition" "اقتراح"
"Question" "سؤال"
"Remark" "تنبيه"
"Scheme" "مخطط"
"Solution" "حل"
"Summary" "موجز"
"Tableau" "جدول"
"Theorem" "نظرية"
End

Translation bg
"Acknowledgement" "Acknowledgement"
"Algorithm" "Aлгоритъм"
"Assumption" "Assumption"
"Axiom" "Axiom"
"Case" "Case"
"Chart" "Chart"
"Claim" "Claim"
"Conclusion" "Заключение"
"Condition" "Условие"
"Conjecture" "Conjecture"
"Corollary" "Corollary"
"Criterion" "Criterion"
"Definition" "Дефиниция"
"Example" "Пример"
"Exercise" "Упражнение"
"Fact" "Факт"
"Graph[[mathematical]]" "Graph"
"Lemma" "Лема"
"List of Algorithms" "List of Algorithms"
"List of Charts" "List of Charts"
"List of Graphs[[mathematical]]" "List of Graphs"
"List of Schemes" "List of Schemes"
"List of Tableaux" "List of Tableaux"
"Listing" 

New "LyX Documentation Tools" toolbar

[Georg Baum]

FYI: I just added a new toolbar (off by default) to LyX 2.2dev for people 
working on the documentation. It gives easy access to LyX and LaTeX logos 
(bug 9626), which are no longer produced automatically if the phrases occur 
in the text, so you do not need ERT separators anymore to prevent that), and 
the info and menu separator insets. If there are other documentation 
specific lfuns which I forgot we can easily add them as well.


Georg

Re: Last call for translations and layout translations review for LyX 2.1.0

[Georg Baum]

I have a comment concerning the german translation changes regarding

Chart = Diagramm (instead of Zeichnung in 2.0)
Graph = Schaubild (instead of Graph in 2.0)

These changes assume that both Chart and Graph are more or less the same 
thing, as used e.g. here: 
http://en.wikipedia.org/wiki/Wikipedia:Graphs_and_charts. If you look for 
these terms in http://dict.leo.org, you'll see that Chart can be 
translated both to Diagramm and Schaubild, and Graph can be translated 
both to Diagramm and Schaubild as well.

Since both terms are only used in achemso.layout I don't think that the 
achemso authors provided environments for the same thing using two names. I 
rather think that Chart is used for graphical representation of data as  
in http://en.wikipedia.org/wiki/Wikipedia:Graphs_and_charts, and Graph is 
used for mathematical graphs as in 
http://en.wikipedia.org/wiki/Graph_(mathematics) (they are used in chemistry 
as well: http://en.wikipedia.org/wiki/Chemical_graph_theory). Therefore I 
propose the following translations (and we should add an disambiguation 
string):

Chart = Diagramm
Graph[[mathematical]] = Graph

Sorry for not sending this earlier, I was unfortunately too busy.


Georg

Re: Last call for translations and layout translations review for LyX 2.1.0

[Georg Baum]

I have a comment concerning the german translation changes regarding

"Chart" => "Diagramm" (instead of "Zeichnung" in 2.0)
"Graph" => "Schaubild" (instead of "Graph" in 2.0)

These changes assume that both Chart and Graph are more or less the same 
thing, as used e.g. here: 
http://en.wikipedia.org/wiki/Wikipedia:Graphs_and_charts. If you look for 
these terms in http://dict.leo.org, you'll see that "Chart" can be 
translated both to "Diagramm" and "Schaubild", and "Graph" can be translated 
both to "Diagramm" and "Schaubild" as well.

Since both terms are only used in achemso.layout I don't think that the 
achemso authors provided environments for the same thing using two names. I 
rather think that "Chart" is used for graphical representation of data as  
in http://en.wikipedia.org/wiki/Wikipedia:Graphs_and_charts, and "Graph" is 
used for mathematical graphs as in 
http://en.wikipedia.org/wiki/Graph_(mathematics) (they are used in chemistry 
as well: http://en.wikipedia.org/wiki/Chemical_graph_theory). Therefore I 
propose the following translations (and we should add an disambiguation 
string):

"Chart" => "Diagramm"
"Graph[[mathematical]]" => "Graph"

Sorry for not sending this earlier, I was unfortunately too busy.


Georg

Re: Translations of Math environments in LyX output - last call for LyX 2.0

[Georg Baum]

Jean-Pierre Chrétien wrote:

 I don't unserstand what happened, a lot of strings which are not
 translated in frenchb.ldf have disappeared.

Yes. This was done intentionally, because these strings are not needed for 
most languages. Note that you can readd these translations manually to 
lib/layouttranslations if needed, and they will stay in the future. I can't 
judge whether this is a good idea, but it is technically possible.


Georg

Re: Translations of Math environments in LyX output - last call for LyX 2.0

[Georg Baum]

Jean-Pierre Chrétien wrote:

> I don't unserstand what happened, a lot of strings which are not
> translated in frenchb.ldf have disappeared.

Yes. This was done intentionally, because these strings are not needed for 
most languages. Note that you can readd these translations manually to 
lib/layouttranslations if needed, and they will stay in the future. I can't 
judge whether this is a good idea, but it is technically possible.


Georg

Re: Rearranged LyX-doc image locations

[Georg Baum]

Uwe Stöhr wrote:

 Jean-Marc Lasgouttes schrieb:
 
 We have to decide what clipart/ really is. If it is just a place where
 to stick images for the docs, then I agree that language dependent
 directories. And it should probably be renamed to images/ or somesuch.
 
 This folder is only for graphics used in the docs and have always been.
 Renaming is not necessary as the folder contains not only images but could
 also icons etc.

If the folder is supposed to contain only images for the documentation then
the name clipart is inappropriate. Clipart implies that there are some
figures that you can use in your own documents, and this is not the case.
If we want to have such a folder we should probably use what
http://www.openclipart.org/ provides. AFAIK this is part of debian and suse
anyway.
To me it looks as if we will never have such a folder, so you should rename
all clipart folders to 'images'.


Georg

Re: Rearranged LyX-doc image locations

[Georg Baum]

Uwe Stöhr wrote:

> Jean-Marc Lasgouttes schrieb:
> 
>> We have to decide what clipart/ really is. If it is just a place where
>> to stick images for the docs, then I agree that language dependent
>> directories. And it should probably be renamed to images/ or somesuch.
> 
> This folder is only for graphics used in the docs and have always been.
> Renaming is not necessary as the folder contains not only images but could
> also icons etc.

If the folder is supposed to contain only images for the documentation then
the name clipart is inappropriate. Clipart implies that there are some
figures that you can use in your own documents, and this is not the case.
If we want to have such a folder we should probably use what
http://www.openclipart.org/ provides. AFAIK this is part of debian and suse
anyway.
To me it looks as if we will never have such a folder, so you should rename
all clipart folders to 'images'.


Georg

Re: PO files FAQ

[Georg Baum]

Am Montag, 5. März 2007 20:34 schrieb Ramon Flores:
 Hi,
 
 I think it is a very good idea to write this FAQ, and to put it in the 
wiki.

That would be the fourth place where this is documented. Please have a look 
at this bug: http://bugzilla.lyx.org/show_bug.cgi?id=3314

 So I would like to make some comments:
 
 1) Not always LANG variable works. Sometimes is necessary to use another 
 variable. For example with Mandriva 2006 with KDE you need to use 
KDE_LANG, 
 and with Mandriva 2007, and KDE, it is necessary to use LC_ALL. Ex:
   a) KDE_LANG=xx_CC lyx
   b) LC_ALL=xx_CC lyx

That should be filed as a mandriva bug. It should not be needed to set 
KDE_LANG. Only setting LANG (or LC_MESSAGES or LC_ALL) should work.


Georg

Re: PO files FAQ

[Georg Baum]

Am Montag, 5. März 2007 20:34 schrieb Ramon Flores:
> Hi,
> 
> I think it is a very good idea to write this FAQ, and to put it in the 
wiki.

That would be the fourth place where this is documented. Please have a look 
at this bug: http://bugzilla.lyx.org/show_bug.cgi?id=3314

> So I would like to make some comments:
> 
> 1) Not always LANG variable works. Sometimes is necessary to use another 
> variable. For example with Mandriva 2006 with KDE you need to use 
KDE_LANG, 
> and with Mandriva 2007, and KDE, it is necessary to use LC_ALL. Ex:
>   a) KDE_LANG=xx_CC lyx
>   b) LC_ALL=xx_CC lyx

That should be filed as a mandriva bug. It should not be needed to set 
KDE_LANG. Only setting LANG (or LC_MESSAGES or LC_ALL) should work.


Georg

Re: Rearranged LyX-doc image locations

[Georg Baum]

Am Sonntag, 4. März 2007 04:29 schrieb Uwe Stöhr:
 Dear LyX-documentation developers,
 
 after JMarc's last change that now every language has its own folder in 
LyX's SVN repository:
 http://www.lyx.org/trac/browser/lyx-devel/trunk/lib/doc/
 
 I rearranged the clipart folder in the following way to fullfill the new 
scheme:
 
 - the clipart folder under /lib was moved to /lib/doc
 - this clipart folder now only contains the language independent and 
English images
 - now every language has it's own clipart folder for language-specific 
images like screenshots
(this currently only affects Spanish)
 All changes only affects LyX's SVN trunk (LyX 1.5)!

You should discuss things like this first. For example, Jean-Marc wrote 
some time ago that the name 'clipart' is not really appropriate.


Georg

Re: Rearranged LyX-doc image locations

[Georg Baum]

Am Sonntag, 4. März 2007 04:29 schrieb Uwe Stöhr:
> Dear LyX-documentation developers,
> 
> after JMarc's last change that now every language has its own folder in 
LyX's SVN repository:
> http://www.lyx.org/trac/browser/lyx-devel/trunk/lib/doc/
> 
> I rearranged the clipart folder in the following way to fullfill the new 
scheme:
> 
> - the clipart folder under /lib was moved to /lib/doc
> - this clipart folder now only contains the language independent and 
English images
> - now every language has it's own clipart folder for language-specific 
images like screenshots
>(this currently only affects Spanish)
> All changes only affects LyX's SVN trunk (LyX 1.5)!

You should discuss things like this first. For example, Jean-Marc wrote 
some time ago that the name 'clipart' is not really appropriate.


Georg

Re: Technical Help Needed About Translating the LyX UI

[Georg Baum]

Ran Rutenberg wrote:

 Dear Translators,
 
 I would like to start translating the LyX UI into Hebrew, but I ran
 into some problems. I tried to open the he.po file using a software
 called poEdit (I am running Windows XP) but I get an error that says
 Failed to convert file contents to Unicode.

I don't know poEdit, but it probably fails because the encoding of he.po is
wrongly defined:

Content-Type: text/plain; charset=iso-8859-1

Open the file in a text editor and set that declaration to the encoding that
is actually used (maybe iso-8859-8?). After that poEdit should be able to
open the file.


Georg

Re: Technical Help Needed About Translating the LyX UI

[Georg Baum]

Ran Rutenberg wrote:

> Dear Translators,
> 
> I would like to start translating the LyX UI into Hebrew, but I ran
> into some problems. I tried to open the he.po file using a software
> called poEdit (I am running Windows XP) but I get an error that says
> "Failed to convert file contents to Unicode".

I don't know poEdit, but it probably fails because the encoding of he.po is
wrongly defined:

Content-Type: text/plain; charset=iso-8859-1

Open the file in a text editor and set that declaration to the encoding that
is actually used (maybe iso-8859-8?). After that poEdit should be able to
open the file.


Georg

Re: Restarting the LyX documentation project

[Georg Baum]

Uwe Stöhr wrote:

 Hello LyXers,
 
 I want to restart to work on the documentation but at first want to have
 you OK about the HOW.

Great!

 The documentation is currently out of date, many menu names have changed
 since the last release, new features like change tracking are not or not
 properly explained.
 Then main problem I see is that we don't have somebody who's actively
 working on the documentation. But besides this the inconsistent
 documentation we currently have is a result that the developer of a new
 feature add a section to the userguide without cross-checking if the
 section is consistent with others. That can be excused due to lack of
 time but for the future I propose this way:

Consistency is nice, but more important is that a feature is documented at
all. You have a chance to find something in a badly organised manual, you
don't have a chance to find something that is not contained in the manual.

 ---
 When a new feature is implemented to be released in the next LyX version
 the developer(s) who wrote the feature create a separate LyX-document
 describing the feature. Then somebody who wasn't involved in the
 development of the feature checks if he's able to use the feature as
 described. This would help us to implement features user friendly
 because the revisers of the document will lead to feedback about the
 implementation, the usability and the stability of the feature before
 the feature is released. If the feature is stable its describing
 document is implemented into the userguide.

This is too complicated IMO. I would already be very pleased if developers
who implement a new feature/rearrange menu entries would simply add a
section to the appropriate manual/reflect the changed menus.

I fear that if these things have to be implemented in a separate document
documentation updates will happen even less than it currently does.


By all means it should be avoided that translated docs become more
recent/contain more information. This is the case with the current german
userguide, but if other languages start to do this too we get a mess. The
english version is the master version, the other languges should be kept up
to date by the translators.


Uwe, I think that you should work on the official documentation from the
beginning, and put it frequently in svn. Otherwise I fear that we'll get a
situation similar to your windows installer where there was a lot of
duplicated effort.


Georg

Re: Restarting the LyX documentation project

[Georg Baum]

Uwe Stöhr wrote:

 Georg Baum schrieb:
 
 When a new feature is implemented to be released in the next LyX version
 the developer(s) who wrote the feature create a separate LyX-document
 describing the feature. Then somebody who wasn't involved in the
 development of the feature checks if he's able to use the feature as
 described. This would help us to implement features user friendly
 because the revisers of the document will lead to feedback about the
 implementation, the usability and the stability of the feature before
 the feature is released. If the feature is stable its describing
 document is implemented into the userguide.
 
 This is too complicated IMO. I would already be very pleased if
 developers who implement a new feature/rearrange menu entries would
 simply add a section to the appropriate manual/reflect the changed menus.
 
 For me it is easier to have separate small document describing the new
 feature. I'll revise it and then inlude it to the official docs. This
 has the advantage that a professional bug finder ;-) will give feedback.

I can understand that. My point is this: If I have to choose between
suboptimal written documentation without having a professional bugfinder
looking at it, or no documentation at all I prefer the suboptimal version.

 I fear that if these things have to be implemented in a separate document
 documentation updates will happen even less than it currently does.
 
 You misunderstood me, the separate documents are only for the
 development, they won't be published but included to the official docs.

I don't think that I misunderstood you. I do want development happen in the
userguide (and the other existing documents of course). IMO, with the
procedure

- implement new feature
- commit the code changes
- create new doc describing it
- put new doc in svn and commit it
- sometimes later, move contents from new doc to Userguide, remove the new
doc from svn and commit all that

documentation updates are much less likely to happen than with

- implement new feature
- describe it in the user guide
- commit the code + documentation changes

And all the documentation needs to be in svn IMO. If it is not it will be
forgotten and not seen by many people. But even if you skip the svn part
for the new doc and put it on the wiki instead it would still be
considerable more work. Given the fact that many new features are currently
not documented at all, without the requirement of separate docs, I very
much doubt that you would get better documenetation if you require separate
docs.

 Uwe, I think that you should work on the official documentation from the
 beginning, and put it frequently in svn. Otherwise I fear that we'll get
 a situation similar to your windows installer where there was a lot of
 duplicated effort.
 
 But that's what I want to do. To say it graphically:
 
 separate document for new feature
  | |
  ^ ^
 special document  ---   Userguide
   basics
 
 So it ends up in the Userguide.
 
 And by the way, I plan that the version UserguideNV I'm working on will
 become the official version. It is very similar to the actual userguide
 but includes more informations about the UI.

I don't have time to look at that yet, but IMO you really should do this
work in svn and not somewhere outside the official LyX project. I can
assure you that if you come when it is finished and want to replace the
current Userguide there will be objections, and the result will either be
additional work for you to get it accepted, or your version will never show
up in the official sources.

If you do your work in svn, on the current version with frequent commits,
then it will be less work in the end, because no big change will come at
once, and if there are objections to one step you will get to know them
immediately, and they can be resolved quickly.


Georg

Re: Restarting the LyX documentation project

[Georg Baum]

Uwe Stöhr wrote:

> Hello LyXers,
> 
> I want to restart to work on the documentation but at first want to have
> you OK about the HOW.

Great!

> The documentation is currently out of date, many menu names have changed
> since the last release, new features like change tracking are not or not
> properly explained.
> Then main problem I see is that we don't have somebody who's actively
> working on the documentation. But besides this the inconsistent
> documentation we currently have is a result that the developer of a new
> feature add a section to the userguide without cross-checking if the
> section is consistent with others. That can be excused due to lack of
> time but for the future I propose this way:

Consistency is nice, but more important is that a feature is documented at
all. You have a chance to find something in a badly organised manual, you
don't have a chance to find something that is not contained in the manual.

> ---
> When a new feature is implemented to be released in the next LyX version
> the developer(s) who wrote the feature create a separate LyX-document
> describing the feature. Then somebody who wasn't involved in the
> development of the feature checks if he's able to use the feature as
> described. This would help us to implement features user friendly
> because the revisers of the document will lead to feedback about the
> implementation, the usability and the stability of the feature before
> the feature is released. If the feature is stable its describing
> document is implemented into the userguide.

This is too complicated IMO. I would already be very pleased if developers
who implement a new feature/rearrange menu entries would simply add a
section to the appropriate manual/reflect the changed menus.

I fear that if these things have to be implemented in a separate document
documentation updates will happen even less than it currently does.


By all means it should be avoided that translated docs become more
recent/contain more information. This is the case with the current german
userguide, but if other languages start to do this too we get a mess. The
english version is the master version, the other languges should be kept up
to date by the translators.


Uwe, I think that you should work on the official documentation from the
beginning, and put it frequently in svn. Otherwise I fear that we'll get a
situation similar to your windows installer where there was a lot of
duplicated effort.


Georg

Re: Restarting the LyX documentation project

[Georg Baum]

Uwe Stöhr wrote:

> Georg Baum schrieb:
> 
>>> When a new feature is implemented to be released in the next LyX version
>>> the developer(s) who wrote the feature create a separate LyX-document
>>> describing the feature. Then somebody who wasn't involved in the
>>> development of the feature checks if he's able to use the feature as
>>> described. This would help us to implement features user friendly
>>> because the revisers of the document will lead to feedback about the
>>> implementation, the usability and the stability of the feature before
>>> the feature is released. If the feature is stable its describing
>>> document is implemented into the userguide.
>> 
>> This is too complicated IMO. I would already be very pleased if
>> developers who implement a new feature/rearrange menu entries would
>> simply add a section to the appropriate manual/reflect the changed menus.
> 
> For me it is easier to have separate small document describing the new
> feature. I'll revise it and then inlude it to the official docs. This
> has the advantage that a professional bug finder ;-) will give feedback.

I can understand that. My point is this: If I have to choose between
suboptimal written documentation without having a professional bugfinder
looking at it, or no documentation at all I prefer the suboptimal version.

>> I fear that if these things have to be implemented in a separate document
>> documentation updates will happen even less than it currently does.
> 
> You misunderstood me, the separate documents are only for the
> development, they won't be published but included to the official docs.

I don't think that I misunderstood you. I do want development happen in the
userguide (and the other existing documents of course). IMO, with the
procedure

- implement new feature
- commit the code changes
- create new doc describing it
- put new doc in svn and commit it
- sometimes later, move contents from new doc to Userguide, remove the new
doc from svn and commit all that

documentation updates are much less likely to happen than with

- implement new feature
- describe it in the user guide
- commit the code + documentation changes

And all the documentation needs to be in svn IMO. If it is not it will be
forgotten and not seen by many people. But even if you skip the svn part
for the new doc and put it on the wiki instead it would still be
considerable more work. Given the fact that many new features are currently
not documented at all, without the requirement of separate docs, I very
much doubt that you would get better documenetation if you require separate
docs.

>> Uwe, I think that you should work on the official documentation from the
>> beginning, and put it frequently in svn. Otherwise I fear that we'll get
>> a situation similar to your windows installer where there was a lot of
>> duplicated effort.
> 
> But that's what I want to do. To say it graphically:
> 
> separate document for new feature
>  | |
>  ^ ^
> special document  --->   Userguide
>   basics
> 
> So it ends up in the Userguide.
> 
> And by the way, I plan that the version UserguideNV I'm working on will
> become the official version. It is very similar to the actual userguide
> but includes more informations about the UI.

I don't have time to look at that yet, but IMO you really should do this
work in svn and not somewhere outside the official LyX project. I can
assure you that if you come when it is finished and want to replace the
current Userguide there will be objections, and the result will either be
additional work for you to get it accepted, or your version will never show
up in the official sources.

If you do your work in svn, on the current version with frequent commits,
then it will be less work in the end, because no big change will come at
once, and if there are objections to one step you will get to know them
immediately, and they can be resolved quickly.


Georg

Re: Auto generation of lfun wiki page

[Georg Baum]

Am Samstag, 11. Juni 2005 19:23 schrieb Lars Gullik Bjønnes:
 Georg Baum [EMAIL PROTECTED] writes:
 | Why? Adding documentation, be it as comments or as strings in a new 
 | (otherwise unused) member of the ev_item struct cannot introduce bugs 
or 
 | influence the release of 1.4 in any other way. Or do I miss something?
 
 Except delaying it of course...

Maybe. Of course we get delays if lfuns need to be discussed on the list, 
but that is independent from the documentation format. If we don't want 
that we should freeze the lfun documentation until 1.4.0 is released.
Then we get delays if somebody without CVS access wants patches to be 
applied, but that could be minimized if e.g. Christian has CVS access.


Georg

Re: Auto generation of lfun wiki page

[Georg Baum]

Am Samstag, 11. Juni 2005 19:23 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
> | Why? Adding documentation, be it as comments or as strings in a new 
> | (otherwise unused) member of the ev_item struct cannot introduce bugs 
or 
> | influence the release of 1.4 in any other way. Or do I miss something?
> 
> Except delaying it of course...

Maybe. Of course we get delays if lfuns need to be discussed on the list, 
but that is independent from the documentation format. If we don't want 
that we should freeze the lfun documentation until 1.4.0 is released.
Then we get delays if somebody without CVS access wants patches to be 
applied, but that could be minimized if e.g. Christian has CVS access.


Georg

[patch] document external templates

[Georg Baum]

The attached documentation update has been lying half finished on my disk 
for a long time. I documented editors and copiers very briefly. The main 
changes are to the external material section. It is hopelessly out of 
date. I added some notes stating just that, because I don't know what to 
write instead of the old stuff.
Last, but not least I started to document the external template definition 
file. This is just a start and may even contain errors, but IMHO better 
than no documentation at all.
This goes in if nobody complains.


Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/lib/doc/ChangeLog lyx-1.4-cvs/lib/doc/ChangeLog
--- lyx-1.4-clean/lib/doc/ChangeLog	2004-12-19 11:36:07.0 +0100
+++ lyx-1.4-cvs/lib/doc/ChangeLog	2005-01-30 13:41:29.0 +0100
@@ -1,3 +1,8 @@
+2005-01-30  Georg Baum  [EMAIL PROTECTED]
+
+	* Customization.lyx: document the external template definition file
+	* Customization.lyx: document editors and copiers
+
 2004-12-16  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
 
 	* LaTeXConfig.lyx.in: change a bit the description of language
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/lib/doc/Customization.lyx lyx-1.4-cvs/lib/doc/Customization.lyx
--- lyx-1.4-clean/lib/doc/Customization.lyx	2004-11-23 09:16:45.0 +0100
+++ lyx-1.4-cvs/lib/doc/Customization.lyx	2005-01-30 15:08:02.0 +0100
@@ -1605,11 +1605,11 @@ Submenu
 s.
 \layout Section
 
-Converters, Formats and Viewers
+Converters, Formats, Viewers, Editors and Copiers
 \layout Standard
 
-LyX has a new and powerful mechanism to convert to and from any file format
- using external programs.
+LyX has a powerful mechanism to convert to and from any file format using
+ external programs.
  Define a pair of formats, e.g.
 
 \family typewriter 
@@ -1666,7 +1666,7 @@ ools\SpecialChar \menuseparator
 \bar under 
 P
 \bar default 
-references:Converters
+references:Conversion
 \family default 
  dialog.
  For example, to change the 
@@ -1689,6 +1689,55 @@ M
 odify
 \family default 
 .
+\layout Standard
+
+Editors are like viewers: Each Format can have an Editor associated to it,
+ and they can be altered via the 
+\family sans 
+\bar under 
+T
+\bar default 
+ools\SpecialChar \menuseparator
+
+\bar under 
+P
+\bar default 
+references:Conversion
+\family default 
+ dialog.
+ LyX uses them whenever an included file
+\begin_inset Foot
+collapsed true
+
+\layout Standard
+
+This can be an included 
+\family typewriter 
+.tex
+\family default 
+ file, a verbatim included text file, external material or an included graphics
+ file.
+\end_inset 
+
+ needs to be edited.
+\layout Standard
+
+Finally, each Format can have a Copier associated to it.
+ Since all conversions from one Format to another take place in a temporary
+ directory, it is sometimes necessary to modify a file before copying it
+ to the temporary directory
+\begin_inset Foot
+collapsed true
+
+\layout Standard
+
+For example, the file may reference other files with relative filenames,
+ which will become invalid in the temporary directory
+\end_inset 
+
+.
+ This is done by the Copier: It copies a file to (or from) the temporary
+ directory and may modify it in the process.
 \layout Section
 
 BibTeX and makeindex
@@ -4693,7 +4742,7 @@ There are two situations you are likely 
 ) files.
 \layout Subsection
 
-A layout for an 
+A layout for a 
 \family sans 
 sty
 \family default 
@@ -7470,6 +7519,15 @@ Including External Material
 Background
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This section is completely outdated.
+\end_inset 
+
 One often requested feature from LyX users is to be able to interface LyX
  with XFig, Dia, or other similar applications that specialize in producing
  a certain kind of diagram, figure, schematic or whatever material might
@@ -7610,6 +7668,15 @@ ghostview
  ultimately be more productive.
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This paragraph is outdated
+\end_inset 
+
 So, all in all, LyX has information about a number of different programs
  to use behind the scenes in order to realize all of this machinery.
  This information, in fact, is exactly what is contained in the templates.
@@ -7670,6 +7737,15 @@ nsert
  view, edit or produce the material that is used in the resulting file.
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This paragraph is outdated
+\end_inset 
+
 At the top of this dialog, there is a drop-down list where you can chose
  which template should be used.
  Just below the template drop-down, there's a text area with a short blurb
@@ -7691,6 +7767,15 @@ Browse
  no need to give access to it in the user interface.
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This paragraph is outdated
+\end_inset 
+
 At the bottom of the dialog, you'll find a general input box called 
 \family sans 
 Parameters
@@ -7702,6 +7787,15 @@ Parameters
  file should be generated.
 \layout

[patch] document external templates

[Georg Baum]

The attached documentation update has been lying half finished on my disk 
for a long time. I documented editors and copiers very briefly. The main 
changes are to the external material section. It is hopelessly out of 
date. I added some notes stating just that, because I don't know what to 
write instead of the old stuff.
Last, but not least I started to document the external template definition 
file. This is just a start and may even contain errors, but IMHO better 
than no documentation at all.
This goes in if nobody complains.


Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/lib/doc/ChangeLog lyx-1.4-cvs/lib/doc/ChangeLog
--- lyx-1.4-clean/lib/doc/ChangeLog	2004-12-19 11:36:07.0 +0100
+++ lyx-1.4-cvs/lib/doc/ChangeLog	2005-01-30 13:41:29.0 +0100
@@ -1,3 +1,8 @@
+2005-01-30  Georg Baum  <[EMAIL PROTECTED]>
+
+	* Customization.lyx: document the external template definition file
+	* Customization.lyx: document editors and copiers
+
 2004-12-16  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
 
 	* LaTeXConfig.lyx.in: change a bit the description of language
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/lib/doc/Customization.lyx lyx-1.4-cvs/lib/doc/Customization.lyx
--- lyx-1.4-clean/lib/doc/Customization.lyx	2004-11-23 09:16:45.0 +0100
+++ lyx-1.4-cvs/lib/doc/Customization.lyx	2005-01-30 15:08:02.0 +0100
@@ -1605,11 +1605,11 @@ Submenu
 s.
 \layout Section
 
-Converters, Formats and Viewers
+Converters, Formats, Viewers, Editors and Copiers
 \layout Standard
 
-LyX has a new and powerful mechanism to convert to and from any file format
- using external programs.
+LyX has a powerful mechanism to convert to and from any file format using
+ external programs.
  Define a pair of formats, e.g.
 
 \family typewriter 
@@ -1666,7 +1666,7 @@ ools\SpecialChar \menuseparator
 \bar under 
 P
 \bar default 
-references:Converters
+references:Conversion
 \family default 
  dialog.
  For example, to change the 
@@ -1689,6 +1689,55 @@ M
 odify
 \family default 
 .
+\layout Standard
+
+Editors are like viewers: Each Format can have an Editor associated to it,
+ and they can be altered via the 
+\family sans 
+\bar under 
+T
+\bar default 
+ools\SpecialChar \menuseparator
+
+\bar under 
+P
+\bar default 
+references:Conversion
+\family default 
+ dialog.
+ LyX uses them whenever an included file
+\begin_inset Foot
+collapsed true
+
+\layout Standard
+
+This can be an included 
+\family typewriter 
+.tex
+\family default 
+ file, a verbatim included text file, external material or an included graphics
+ file.
+\end_inset 
+
+ needs to be edited.
+\layout Standard
+
+Finally, each Format can have a Copier associated to it.
+ Since all conversions from one Format to another take place in a temporary
+ directory, it is sometimes necessary to modify a file before copying it
+ to the temporary directory
+\begin_inset Foot
+collapsed true
+
+\layout Standard
+
+For example, the file may reference other files with relative filenames,
+ which will become invalid in the temporary directory
+\end_inset 
+
+.
+ This is done by the Copier: It copies a file to (or from) the temporary
+ directory and may modify it in the process.
 \layout Section
 
 BibTeX and makeindex
@@ -4693,7 +4742,7 @@ There are two situations you are likely 
 ) files.
 \layout Subsection
 
-A layout for an 
+A layout for a 
 \family sans 
 sty
 \family default 
@@ -7470,6 +7519,15 @@ Including External Material
 Background
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This section is completely outdated.
+\end_inset 
+
 One often requested feature from LyX users is to be able to interface LyX
  with XFig, Dia, or other similar applications that specialize in producing
  a certain kind of diagram, figure, schematic or whatever material might
@@ -7610,6 +7668,15 @@ ghostview
  ultimately be more productive.
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This paragraph is outdated
+\end_inset 
+
 So, all in all, LyX has information about a number of different programs
  to use behind the scenes in order to realize all of this machinery.
  This information, in fact, is exactly what is contained in the templates.
@@ -7670,6 +7737,15 @@ nsert
  view, edit or produce the material that is used in the resulting file.
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This paragraph is outdated
+\end_inset 
+
 At the top of this dialog, there is a drop-down list where you can chose
  which template should be used.
  Just below the template drop-down, there's a text area with a short blurb
@@ -7691,6 +7767,15 @@ Browse
  no need to give access to it in the user interface.
 \layout Standard
 
+
+\begin_inset Note
+collapsed true
+
+\layout Standard
+
+This paragraph is outdated
+\end_inset 
+
 At the bottom of the dialog, you'll find a general input box called 
 \family sans 
 Parameters
@@ -7702,6 +7787,15 @@ Parameters
  file should 

Re: [rework docs] reasons, plans, questions

[Georg Baum]

Am Sonntag, 9. Januar 2005 15:34 schrieb Uwe Stöhr:

 I started with the UserGuide found in the CVS under lib/docs. I thaught 
 it is the version for LyX 1.4. If not where can I get the right one?

This is correct if it is the HEAD branch. I thought you used 1.3 because 
you wrote that you wanted to update the 1.3 documentation originally.


Georg

Re: [rework docs] questions part two

[Georg Baum]

Am Sonntag, 9. Januar 2005 16:26 schrieb Uwe Stöhr:

 The layout and example files needn't to be changed when beamer comes up 
 with a new version. I tested the actual files hardly and improved them 
 together with the beamer author, so that they are stable since beamer 2 
 (the actual one is beamer 3.1).

The fact that it was like that in the past does not mean that it will not 
be necessary in the future, but form what you say I guess it is at least 
unlikely.

  2. More effort for .rpm and .deb creators. At least debian has a 
  latex-beamer package that contains the latex and lyx files. If lyx 
would 
  also contain the files, there would be a conflict, so they must be 
  excluded from the .deb package.
 
 Why that? All we have to do, is to copy the files to the folders 
 lyx/share/lyx/layouts etc. So why do files in different folders cause 
 trouble?

Because they are not in different folders. The debian package latex-beamer 
(in .deb format) installs them (ready for use) under /usr/share/lyx. I 
don't know if there exist .rpm packages for latex-beamer, but if they do, 
and if they are packaged carefully, they'll do the same. So all a user 
has to do is to install both latex-beamer and lyx, and he has everything 
he needs. If the lyx package would contain the beamer files, latex-beamer 
and lyx would not be installable at the same time. Therefore the 
packagers would need to tweak the lyx install process to exclude the 
beamer files.

Of course the situation changes if lyx was the primary source for the 
files and they were not contained in latex-beamer anymore.

 manually. So I thaught we can do this for the user by deliver the files 
 with the Lyx package.

I understood that. In fact, I don't really care very much, but I only 
wanted to make clear that this would also create more work at other 
places. 


Georg

Re: [rework docs] reasons, plans, questions

[Georg Baum]

Am Sonntag, 9. Januar 2005 15:34 schrieb Uwe Stöhr:

> I started with the UserGuide found in the CVS under lib/docs. I thaught 
> it is the version for LyX 1.4. If not where can I get the right one?

This is correct if it is the HEAD branch. I thought you used 1.3 because 
you wrote that you wanted to update the 1.3 documentation originally.


Georg

Re: [rework docs] questions part two

[Georg Baum]

Am Sonntag, 9. Januar 2005 16:26 schrieb Uwe Stöhr:

> The layout and example files needn't to be changed when beamer comes up 
> with a new version. I tested the actual files hardly and improved them 
> together with the beamer author, so that they are stable since beamer 2 
> (the actual one is beamer 3.1).

The fact that it was like that in the past does not mean that it will not 
be necessary in the future, but form what you say I guess it is at least 
unlikely.

> > 2. More effort for .rpm and .deb creators. At least debian has a 
> > latex-beamer package that contains the latex and lyx files. If lyx 
would 
> > also contain the files, there would be a conflict, so they must be 
> > excluded from the .deb package.
> 
> Why that? All we have to do, is to copy the files to the folders 
> lyx/share/lyx/layouts etc. So why do files in different folders cause 
> trouble?

Because they are not in different folders. The debian package latex-beamer 
(in .deb format) installs them (ready for use) under /usr/share/lyx. I 
don't know if there exist .rpm packages for latex-beamer, but if they do, 
and if they are packaged carefully, they'll do the same. So all a user 
has to do is to install both latex-beamer and lyx, and he has everything 
he needs. If the lyx package would contain the beamer files, latex-beamer 
and lyx would not be installable at the same time. Therefore the 
packagers would need to tweak the lyx install process to exclude the 
beamer files.

Of course the situation changes if lyx was the primary source for the 
files and they were not contained in latex-beamer anymore.

> manually. So I thaught we can do this for the user by deliver the files 
> with the Lyx package.

I understood that. In fact, I don't really care very much, but I only 
wanted to make clear that this would also create more work at other 
places. 


Georg