LyX wiki recent wiki posts
Recent wiki posts: (http://wiki.lyx.org/Field/AllRecentChanges) (http://wiki.lyx.org/devel/pmwiki.php/Field/AllRecentChanges) * http://wiki.lyx.org/Site/GroupHeader-site - 16:17 24/10 by chr * http://wiki.lyx.org/LyX/FeaturePoll - 16:38 24/10 by Andrej Bona
Re: The New Hebrew Translation of the Introduction
Ran == Ran Rutenberg [EMAIL PROTECTED] writes: Ran Hi, I finally finished making a new translation into Hebrew of Ran the Introduction. This translation is updated in comparison to Ran the old one dated back to 2002. In addition I used the Ran terminology set by The Academy of the Hebrew Language (for some Ran of the terms there wasn't an official translation in 2002). Very good. Ran I will grant permission to license my contributions to LyX under Ran the Gnu General Public License, version 2 or later. Thanks for that. Ran Now all I need to know is to where do I send the file (36KB)? Send it here. JMarc
Re: Restarting the LyX documentation project
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 == Georg Baum [EMAIL PROTECTED] writes: Georg This is too complicated IMO. I would already be very pleased if Georg developers who implement a new feature/rearrange menu entries Georg would simply add a section to the appropriate manual/reflect Georg the changed menus. Georg I fear that if these things have to be implemented in a Georg separate document documentation updates will happen even less Georg than it currently does. Uwe, we would indeed be delighted to have a real doc maintainer. But I agree with Georg that, at least for a first cleanup phase, the work should be done on the main documents. The more ambitious plan can only be carried out if you manage to create a real documentation team, IMO. JMarc
Re: Restarting the LyX documentation project
Jean-Marc Lasgouttes schrieb: Uwe, we would indeed be delighted to have a real doc maintainer. But I agree with Georg that, at least for a first cleanup phase, the work should be done on the main documents. The more ambitious plan can only be carried out if you manage to create a real documentation team, IMO. Then let me try this. But at first please have a look at the UserguideNV: http://wiki.lyx.org/LyX/DocumentationDevelopment and Tables: http://wiki.lyx.org/uploads/LyX/LyXDevelDocumentation/Tables.pdf (http://wiki.lyx.org/uploads/LyX/LyXDevelDocumentation/Tables.rar) that I'm working on and tell me your opinion before I continue to work on the docs. regards Uwe
Re: Restarting the LyX documentation project
Georg Baum schrieb: If there is more documentation in a other language it just becomes a item on the TODO list: translate to English. If that happens with several languges then it will be impossible to update the english version. For example I could do that if only the german version is newer (and maybe the french one if it is not too much text), but I would not be able to adapt changes from the Czech version. I agree, the English version should be the base. Uwe
Re: Restarting the LyX documentation project
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: The New Hebrew Translation of the Introduction
Hi, I've attached the he_intro.lyx to this message. I made some last minute changes so now its size is 40KB. Sincerely, Ran Rutenberg On 10/25/06, Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote: Ran == Ran Rutenberg [EMAIL PROTECTED] writes: Ran Hi, I finally finished making a new translation into Hebrew of Ran the Introduction. This translation is updated in comparison to Ran the old one dated back to 2002. In addition I used the Ran terminology set by The Academy of the Hebrew Language (for some Ran of the terms there wasn't an official translation in 2002). Very good. Ran I will grant permission to license my contributions to LyX under Ran the Gnu General Public License, version 2 or later. Thanks for that. Ran Now all I need to know is to where do I send the file (36KB)? Send it here. JMarc he_Intro.lyx Description: application/lyx
LyX wiki recent wiki posts
Recent wiki posts: (http://wiki.lyx.org/Field/AllRecentChanges) (http://wiki.lyx.org/devel/pmwiki.php/Field/AllRecentChanges) * http://wiki.lyx.org/Site/GroupHeader-site - 16:17 24/10 by chr * http://wiki.lyx.org/LyX/FeaturePoll - 16:38 24/10 by Andrej Bona
Re: The New Hebrew Translation of the Introduction
> "Ran" == Ran Rutenberg <[EMAIL PROTECTED]> writes: Ran> Hi, I finally finished making a new translation into Hebrew of Ran> the Introduction. This translation is updated in comparison to Ran> the old one dated back to 2002. In addition I used the Ran> terminology set by "The Academy of the Hebrew Language" (for some Ran> of the terms there wasn't an official translation in 2002). Very good. Ran> I will grant permission to license my contributions to LyX under Ran> the Gnu General Public License, version 2 or later. Thanks for that. Ran> Now all I need to know is to where do I send the file (36KB)? Send it here. JMarc
Re: Restarting the LyX documentation project
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" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> This is too complicated IMO. I would already be very pleased if Georg> developers who implement a new feature/rearrange menu entries Georg> would simply add a section to the appropriate manual/reflect Georg> the changed menus. Georg> I fear that if these things have to be implemented in a Georg> separate document documentation updates will happen even less Georg> than it currently does. Uwe, we would indeed be delighted to have a real doc maintainer. But I agree with Georg that, at least for a first cleanup phase, the work should be done on the main documents. The more ambitious plan can only be carried out if you manage to create a real documentation team, IMO. JMarc
Re: Restarting the LyX documentation project
Jean-Marc Lasgouttes schrieb: Uwe, we would indeed be delighted to have a real doc maintainer. But I agree with Georg that, at least for a first cleanup phase, the work should be done on the main documents. The more ambitious plan can only be carried out if you manage to create a real documentation team, IMO. Then let me try this. But at first please have a look at the UserguideNV: http://wiki.lyx.org/LyX/DocumentationDevelopment and Tables: http://wiki.lyx.org/uploads/LyX/LyXDevelDocumentation/Tables.pdf (http://wiki.lyx.org/uploads/LyX/LyXDevelDocumentation/Tables.rar) that I'm working on and tell me your opinion before I continue to work on the docs. regards Uwe
Re: Restarting the LyX documentation project
Georg Baum schrieb: If there is more documentation in a other language it just becomes a item on the TODO list: translate to English. If that happens with several languges then it will be impossible to update the english version. For example I could do that if only the german version is newer (and maybe the french one if it is not too much text), but I would not be able to adapt changes from the Czech version. I agree, the English version should be the base. Uwe
Re: Restarting the LyX documentation project
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: The New Hebrew Translation of the Introduction
Hi, I've attached the he_intro.lyx to this message. I made some last minute changes so now its size is 40KB. Sincerely, Ran Rutenberg On 10/25/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > "Ran" == Ran Rutenberg <[EMAIL PROTECTED]> writes: Ran> Hi, I finally finished making a new translation into Hebrew of Ran> the Introduction. This translation is updated in comparison to Ran> the old one dated back to 2002. In addition I used the Ran> terminology set by "The Academy of the Hebrew Language" (for some Ran> of the terms there wasn't an official translation in 2002). Very good. Ran> I will grant permission to license my contributions to LyX under Ran> the Gnu General Public License, version 2 or later. Thanks for that. Ran> Now all I need to know is to where do I send the file (36KB)? Send it here. JMarc he_Intro.lyx Description: application/lyx
