Re: A few questions
On 6 March 2008 16:52:41 Pavel Sanda wrote: > thank you for the detailed description, i'm starting have a clue what you > have in mind. > its clear these two things are orthogonal - at most bilingual mode could > exercise > your WM tool as a part of editing process. Perhaps. I will have to look at it closely first. There may be a way to extend that bilingual mode. > > in case you decide use LyX for your plans it maybe be good to outline the > implemenation here on list before you appear with 100kb of code ;) Right. It will definitely not be a small piece of work. Cheers, Raymond
Re: A few questions
On 6 March 2008 16:13:42 Martin Vermeer wrote: > On Thu, Mar 06, 2008 at 02:39:28PM -0500, Raymond Martin wrote: > > Qt Linguist are really for software localization). Just so you know, > > OmegaT+ can translate documents in HTML/XHTML, ODF, OOo, OOXML, > > PO, Java properties, JavaHelp, DocBook, plaintext, XLIFF, INI. And > > gettext po? That's interesting... that's what we are using. But is > it better than emacs gettext mode? I never used emacs gettext mode, so I would not know. PO support is only rudimentary right now. Raymond
Re: A few questions
On 6 March 2008 14:11:12 you wrote: > On Thu, Mar 06, 2008 at 08:55:56AM -0500, Raymond Martin wrote: > > Okay, it's a concurrency framework being added to Qt 4.4. my mistake. > > More about it: http://trolltech.com/products/qt/whatsnew/qt44-preview > > That's mainly about parallization of very similar task, like rendering > parts of a scene in parallel, image transformation, file sysntem scans > or such. I am sorry, but that is not the case. It a full concurrency framework as should be expected by the name of it - http://doc.trolltech.com/main-snapshot/threads.html#qtconcurrent And it is very similar to what Java has in a number of way. Raymond
Re: A few questions
Andre, On 6 March 2008 14:05:58 you wrote: > On Thu, Mar 06, 2008 at 07:16:55AM -0500, Raymond Martin wrote: > > I agree it would be difficult. The major benefit from my perspective > > is that it would be immediately cross-platform. > > Could you name a single platform for which there is > (a) LyX not available, > (b) Java available, and > (c) an interest to run LyX on? Well, I'm not trying to make a debate here, but by "immediately cross-platform" I meant that it is possible to create your application on one platform and have on the others (that support Java) without having to have it recompiled first. Since my intention is to use QtJambi, not Swing, SWT, or Gtk, It is very likely that a port of LyX to Java would run on just as many platforms as it does now (albeit for some platforms the needed Qt libs would still have to be compiled first, which means it is about the same work to get installed for the Java version as C++ on those and less work on those OS that Trolltech already provides the libs precompiled). > > My first choice for GUI implementation is QtJambi which gives provides > > almost all of Qt to Java. Java also does have some benefits over C++ > > in terms of simplicity and other features. > > That's debatable, especially when talking about C++/Qt vs Java... Sure, there are pros and cons to both C++ and Java. I have programmed in both languages and I used to detest Java. Now I don't and can see it is better than C++ in certain areas, while still having its own problems. Since Trolltech is providing both Qt and QtJambi (which is just Qt with a wrapper) the main difference is a Java interface. > > One that comes to mind is multiple threads, which LyX does not have > > from what I can see (LyX blocks every time you go to view an output > > format). Java would not have an issue like this, but Qt 4.4 is going > > to have multi-threading. Hopefully LyX will move to that version > > quickly. > > Could you stop this nonsense please? Threads have been part of Qt for > ages, and even if they weren't there are several thread implementations > available for use with C and C++. I already stated in another post that I should have said concurrency framework. > The fact that LyX does not use threads extensively is in no way related > to the choice of programming language. Standard C++ does not have threads built in. You need a separate thread library for that (e.g. pthreads). Qt may well have something, but it is not part of C++. On the other hand, Java has always has threads, unlike many other programming languages, it was built from the start that way. Choice of language can have something to do with threads. > > > I am also wondering why LyX does not have dockable widgets planned for > > 1.6. > > Because they are already there. I did not see it in the list of features for 1.6 and it is not there in 1.5. If it is in the application, a list update at some point perhaps. Raymond
Re: A few questions
Andre On 6 March 2008 13:32:52 you wrote: > > The application I am redesigning is mainly for translators (I call it > > a translation processor) and it uses translation memory and TMX > > (translation memory exchange) in its operation. This functionality > > could also be useful to all kinds of writers in general (something I > > have come to term as Writing Memory, as opposed to another term > > Authoring Memory). > > To be honest, I have no clue what you are talking about, and even > http://www.lisa.org/Translation-Memory-e.34.0.html does not really > help me, and as a consequnece I fail to see the connection to LyX. It may not be obvious right now, but just bear with me a little. Many writers, just like translators, often find themselves writing similar things over and over again. WM, as I call it, helps to speed up and maintain a higher level of quality in ones writing by reusing content. There are numbers of different applications starting to show up that include the facility I am bringing to your attention. Some of them even just use TMX, rather than trying to develop a more general or applicable format to the field of writing. Just Google "authoring memory" and you will see that it really is something that is starting to show up it applications intended for writers. > For some reason I have the feeling that software like KBabel or > Qt Linguist might be closer to what you want/need. Already looked at them numbers of times in the past years. In fact, a while ago I took QtLinguist and started to port it to Java (via QtJambi). While these two applications are sort of similar to what OmegaT+ and some newer incarnation of it might do, they are definitely not innovative enough for what I have in mind. LyX has more features that are directly appealing to writers and translators (KBabel and Qt Linguist are really for software localization). Just so you know, OmegaT+ can translate documents in HTML/XHTML, ODF, OOo, OOXML, PO, Java properties, JavaHelp, DocBook, plaintext, XLIFF, INI. And I am also looking at PDF, DjVu, and Qt .ts. So OmegaT+ is way ahead of both of those applications in terms of file support and usage. > > LyX is customizable on varius scales ranging from menus and toolbars to > document classes and math macros. Again, I have no clue what you need > and whether LyX can help you. Those things have little to do with what I am suggesting. Basically, LyX would need to have string matching support, backing store, and a way to present matches to users for reuse. This last part would probably entail the addition of more dialogs/windows to present the user with matches as they move through their document. It may sound crazy if you never heard of this, but it is an everyday thing in Computer Assisted Translation tools, and is now showing up in Authoring Tools and as add on features for wordprocessors. Regards, Raymond
Re: A few questions
Abdel, On 6 March 2008 08:53:05 Abdelrazak Younes wrote: > > > > I agree it would be difficult. The major benefit from my perspective is > > that it > > would be immediately cross-platform. > > Well, Qt (and LyX) is of course cross-platform already; but that's not > what you meant ;-) Right. > > One that comes to mind is multiple threads, which LyX does not have from > > what > > I can see (LyX blocks every time you go to view an output format). Java > > would not > > have an issue like this, but Qt 4.4 is going to have multi-threading. > > Hopefully > > LyX will move to that version quickly. > > This particular problem has nothing to do with Qt and multi-threading. > It'd be very easy to have non blocking export and we already had some > patches for that. It's just that they never were fully finished. But I > agree it's annoying. And Qt has easy multi-treading support and it's > usable at least since Qt4.0 (called QThread). Okay, it's a concurrency framework being added to Qt 4.4. my mistake. More about it: http://trolltech.com/products/qt/whatsnew/qt44-preview > > FWIW, the only area where we can use multi-threading is the autosaving > feature. This is implemented using fork on Unix but is blocking on > Windows. But as saving is very fast, this is not a major problem anyway. > The blocking export is much more annoying indeed. Okay. With the new concurrency framework this can probably be made simpler and more robust. I'll take a look at it myself. > > > > I am also wondering why LyX does not have dockable widgets planned for 1.6. > > Human resources is the key point here... FYI, we did a lot of source > code cleanup in 1.6 so that UI programming is now much more enjoyable > and easy. Good. > > The split pane idea is okay, but detachable widgets are more useful; > > You mean editing work areas? That'd be easy to do but I don't quite see > the benefit. As for other dialogs, some already are dockable (outline, > view source). More is of course possible. Yes, the editing work areas. I think it would be nice. To take it further I would suggest an MDI implementation also. Perhaps a new implementation that combines the two features together. I'll look at the code and see if it is doable (I have experience designing UI professionally). Regards, Raymond
Re: A few questions
Hi Pavel, On 6 March 2008 07:25:59 Pavel Sanda wrote: > > > Does this Writing Memory type feature seems interesting to anyone for use > > in LyX? > > it depends. could you be more verbose what the term "Writing Memory" is and > how its used? > i started some work wrt translation usage of lyx, but dont know if it has > something > in common with your idea. see > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg132588.html Writing Memory(WM) is just a term I have coined for a more general implementation of Translation Memory, so that it would extend to writing overall, not just translation or localization. Translation Memory(TM) is basically just the storage of segments of text for reuse in new translation work. Given the stored text segments, matching algorithms are applied to retrieve exact and inexact alignments/matches that can be used in the course of translation. One of the main standards for TM is TMX (Translation Memory Exchange - http://www.lisa.org/tmx). Similar standards include XLIFF (XML Localization Interchange File Format) and xml:tm (XML text memory). I am a member of LISA (Localization Industry Standards Association) and have been looking closely at these standards. It seems to me there is better way and that would be what I am calling Writing Memory, which combines all the functionality of TMX, XLIFF, and xml:tm into one standard format that can be used for writing content reuse in a broad sense, rather than in a niche application to translation/localization. A TM capable application will use its matching algorithms to return exact and inexact matches as a translator (writer) moves through the each segment of a document. Some of these matches can be auto-propagated when there are multiple segments with the exact same content within a document. Inexact matches can be presented to the translator separate from the document's segments so they can be chosen appropriately and further edited before use. As for WM, it would be very similar to the case of TM except for the fact that a writer will be using previous text in one language only as elements for reuse. This also has some connection to what is known as Controlled Language(CL) in the content creation industries. This is where particular elements of language are strictly enforced in order to produce consistent products across versions or within certain domains. CL also leads to better localization of documents. Basically what I am looking at here for WM is an application that covers particular areas relevant to the Content Management and Globalization industries (this includes globalization, internationalization, localization, and translation). In regard to your post, it looks on first glance that what you are referring to is more like an implementation of bitext (bilingual texts that are aligned at a specific segmentation level). I happen to be a developer on another project that is called bitext2tmx (http://bitext2tmx.sourceforge.net). It is an application to align original and translation texts, via matching, and convert the aligned segments into a TMX for use in a translation memory capable program (e.g. OmegaT+). These programs are known Computer Assisted Translation (CAT) tools; although I use the term Machine-Aided Human Translation [MAHT], a subtype of CA, to be more specific). > > Would a Java port of LyX ever be a consideration? > > i guess this would be very difficult task to accomplish and don't see the > benefit of it. I agree it would be difficult. The major benefit from my perspective is that it would be immediately cross-platform. My first choice for GUI implementation is QtJambi which gives provides almost all of Qt to Java. Java also does have some benefits over C++ in terms of simplicity and other features. One that comes to mind is multiple threads, which LyX does not have from what I can see (LyX blocks every time you go to view an output format). Java would not have an issue like this, but Qt 4.4 is going to have multi-threading. Hopefully LyX will move to that version quickly. I am also wondering why LyX does not have dockable widgets planned for 1.6. The split pane idea is okay, but detachable widgets are more useful; look at QtDesigner in Qt4 as an example (has a multi-window or a single window mode). Raymond
A few questions
Hi, I'm currently in the re-design phase of an application I am working on and I really am wondering how I can either use LyX as its base code or add the functionality from the type of application I have into LyX. The application I am redesigning is mainly for translators (I call it a translation processor) and it uses translation memory and TMX (translation memory exchange) in its operation. This functionality could also be useful to all kinds of writers in general (something I have come to term as Writing Memory, as opposed to another term Authoring Memory). Some of the main problems with moving forward: - original application is in Java - need to port code to/from Java/C++ (Swing/Qt4) - there is the option of QtJambi (but native library support is an issue) - user workflow/paradigm is almost completely different -original application only provides text editor view of content - no real formatting/layout, etc. - LyX code base is significantly larger ... A few questions: Does this Writing Memory type feature seems interesting to anyone for use in LyX? Would a Java port of LyX ever be a consideration? Is there any way to use a plugin type feature with LyX currently (sorry if this is already answered in documentation somewhere)? Please let me know what you think. Raymond Martin (OmegaT+ project manager) OmegaT+ - http://omegatplus.sourceforge.net
