OmegaT+ 1.0.M3 features list - discussion/comments
laseray
After recently receiving a few comments about missing features in
OmegaT+ I have decided to make a general list here of features that
are being worked on or to be considered for the upcoming 1.0.M3
release. I have been away from working on this for a while, but now I
will get down to putting this out soon.
Please feel free to provide comments and other ideas about these
things. Just note that it impossible to provide every feature in the
short term (i.e., for the initial 1.0.M3 release). Nevertheless, if
anyone has some feature ideas that are not too complex to implement I
may still be able to get them in for this release. All good ideas are
open for discussion, so bring them on and they will be put on the list
of things to do even if they cannot get into this version.
Best regards,
Raymond
Possible 1.0.M3 Features:
1. fast(er) project open (functional)
- will only load document segments and project data
- segment matches are done when a segment is activated, not all
done at once when a project is opened, thus the long waits will be
over when loading large TMX, etc.
2. search terms highlighted (functional)
- shows original or translation search terms in highlights to make
them easier to locate
3. translation = original in TMX (todo)
- a relatively straight forward feature to be done
4. shortcuts localization (todo)
- current version only has English related defaults
- these may not correspond to the locale in use
5. document filters (functional/todo)
- revamped PO filter
- Android(incomplete)
6. localizations
- English: UI: current; Docs: Yes
- French: UI: update required; Docs: one of these days
- Spanish: UI: update required; Docs: ?
- Italian: UI: someone volunteered recently, so maybe?; Docs: ?
- Polish: UI: someone volunteered recently, again maybe ; Docs: ?
7. OmegaT+ icon/splash (functional)
- updated: easier to view, better colors, ...
8. text conversion of original/translation documents (todo)
- save out copies of all document segments as plain text versions
- already have this for Java properties
- useful to create TMX in bitext2tmx from other localizations
- expand this to general case
- save separate file that corresponds to each original document
9. Status View (functional)
- shows user messages in a separate view instead of always in status
bar
9. dictionary (on hold)
- testing it a little, but issues remain
10. spellchecking (on hold)
- on hold until 1.0.M3.1/2/...?
- too much to fix currently, dictionary support is not as good as it
could be
11. Machine translation (on hold)
- automatic MT of segments (e.g., Google translate)
- legal ramifications may be of concern to end translators
who will be submitting their clients data to this kind of
service
laseray
> 3. translation = original in TMX (todo)
> - a relatively straight forward feature to be done
put in the functionality weeks ago and forgot to finish up.
Just needed to add a menu entry to turn it on and off. Seems to work
as expected.
I think there are a few more things in there like that, slipped my
mind while off on other things.
Regards,
Raymond
laseray
some version control (VCS) type files/directories
for reading into the application. Version control files and
directories are those for CVS, Subversion, Git,
Visual Source Safe, and so forth. These can lead to errors when
opening a project--there can be locked files
that won't read and so on.
No user intervention is required, it just skips the relevant files
directories of the supported VCS.
Thanks go to Christian Rocher for his contribution on this feature.
Cheers,
Raymond
Silvermoon
post it):
1. We have find, what about having replace??
Would it be difficult to add a replace function? There is a search
option which is accurately placed in the main GUI, it would be nice to
have the ability to replace a word in the whole text. Sometimes
translators find a better translation for a particular term almost at
the end of the process, so we have to change it everywhere else, when
that term happens to be a single segment (a title), it changes
automatically, but when it does not, you have to use the find option,
go to each segent and change it. I would be nice if you could change
the term with one single click.
Of course, this is to be used with terms that ALWAYS have the same
translation.
2. This is something REALLY necessary:
More often than always translators mark particular parts of the text
and then review them later. This could be because the translated term
is a temporary translation and should be corrected later on, or
because the original text makes no sense.
What we normally do is mark the text by changing the font color or
adding any particular mark that can be found later with the search
feature.
What about adding a articular option for labeling the text? I think
there is an option (don't remember if it was in OmegaT or OmegaT+, but
it definitively is in wordfast) for coloring untranslated segments. We
could have something similar to the search term highlighting feature:
it would be a menu entry or shortcut that enables you to mark words/
sentences/segments with the particular "translation problem" flag,
then we could have a "translation difficulty view" or something with
links to the segments (pretty much like the find view in which we see
search results, double click and then the particular segment is
selected in the editor view).
3. Comments
This is very useful: if we could flag difficult segments, it would
also be nice to be able to add comments to segments. For example I
label x segment as "no sense" and then write a comment on it (like in
Word or Writer) "must ask the author what he really meant with this
sentence", or "the wr 'X' has three possible meanings, all of which
make sense in this context, which one did he really mean?"
This is very useful not only for oneself but also for other people, as
sometimes we translate the same text using the same project file.
The challenge here would be to define if comments should be stored in
the tmx or in a separate file. Maybe if we make a comments folder with
particular files that store the comments and tell OmegaT+ what segment
has what comment. This would allow several translators to work on
different sections of the same text and share their comments folder
without having to share the .tmx all the time.
4. Something that everybody seems to miss: a more useful glossary.
Some glossary entries are not just one word, but a long compound:
English = Spanish
Birthplace = lugar de nacimiento
Birthdate = fecha de nacimiento
Some translations are even longer sentences. So it would be time
saving to have an 'add term from glossary' option like wordfast does
(I think). It would paste the glossary's 100% matching word where the
cursor is. How difficult is to do this programming-wise? If that's too
difficult what about having a button next to each word and once you
push it it adds the term right where the cursor is? Or even better, a
toolbar in the glossary view with some buttons for adding a particular
word to the translation view?
5. Speaking of toolbars
Would it be difficult to add a toolbar to the whole app for speeding
up the work? It would have all/some/most of the options found in the
menus, making it faster to work with this tool. If you are interested
in this idea, I have a list of the most used actions (gotten from my/
my colleagues personal experience).
6. Editable glossary
What about having a tool for editing the glossary? Sometimes I find
horrible typos in the glossary, they could even cause the app not to
show a particular term because it looks too different from the one
found in the original thanks to the typo, it is annoying having to
open the file, change the typo, and reload the project. It is also a
good Idea for the initial phase of translation: term recognition.
Translator would open OmegaT+, start reading the original and start
adding the terms from the app itself, it would then create a CSV file
and paste it somewhere, the they would reload the project and start
working.
Right now what you do is just open the file in open office, read,
select terms, look them up, open notepad/gedit/kwrite/whatever and
start writing the terms and their equivalent. If we could do this from
the app itself it would save us time (all that window switching takes
time, really).
7. A minor feature
I see that OmegaT+ can launch the specified browser. What about a menu
entry/shortcut for this? The Internet is one of the translator's most
useful tools, so it would be nice to be able to do it from the app.
Likewise, it could prove really useful if you are translating an HTML
document and what to view it.
Well, that's it. Hope some of this can help you.
Thanks
Raymond Martin
On October 15, 2009 06:03:49 pm Silvermoon wrote:
> I have a ton of ideas here (hope this is the right place and way to
> post it):
Sure.
>
> 1. We have find, what about having replace??
>
> Would it be difficult to add a replace function? There is a search
> option which is accurately placed in the main GUI, it would be nice to
> have the ability to replace a word in the whole text. Sometimes
> translators find a better translation for a particular term almost at
> the end of the process, so we have to change it everywhere else, when
> that term happens to be a single segment (a title), it changes
> automatically, but when it does not, you have to use the find option,
> go to each segent and change it. I would be nice if you could change
> the term with one single click.
>
> Of course, this is to be used with terms that ALWAYS have the same
> translation.
We don't really have a "find", just a search (over the entire set of documents,
TMX, etc.). That is, there is no find function as is usually seen in other
applications (under the Edit menu, for instance). There should be one.
As for a replace function, that also should be as in other applications.
These, and a few other functions, are usually in the Edit menu and
apply only to the current document. So we would have to look at
adding this functionality as expected like that, as well as extending
it to apply across all documents. So a few considerations need to be
taken into account for this to work in a simple (read non-confusing)
manner.
Overall, I believe it is not very difficult to implement.
>
> 2. This is something REALLY necessary:
>
> More often than always translators mark particular parts of the text
> and then review them later. This could be because the translated term
> is a temporary translation and should be corrected later on, or
> because the original text makes no sense.
Basically bookmarks.
> What we normally do is mark the text by changing the font color or
> adding any particular mark that can be found later with the search
> feature.
This is doable, but I have to think about the exact graphical representation
to use for this (font color, font style, separate marker/character?) and see
what makes the most sense.
>
> What about adding a articular option for labeling the text? I think
> there is an option (don't remember if it was in OmegaT or OmegaT+, but
> it definitively is in wordfast) for coloring untranslated segments.
Newer OmegaT versions have coloring of segments, depending on their state.
I am already considering putting this in and I could have just done it the way
they do already, but it looks so ghastly awful (and too much like some
commercial CAT tools with blocky highlighting). It's an eyesore and might
give you sore eyes if you have to stare at that all day long if I just slap
it in.
It is not difficult to implement so it is on the short list for features to come
in the 1.0.M3 series, after this next release though.
> We could have something similar to the search term highlighting feature:
> it would be a menu entry or shortcut that enables you to mark words/
> sentences/segments with the particular "translation problem" flag,
> then we could have a "translation difficulty view" or something with
> links to the segments (pretty much like the find view in which we see
> search results, double click and then the particular segment is
> selected in the editor view).
Unless the intention is just to mark the spot where the cursor is, mouse
selection of the relevant text would be needed before this flag you mention
could be put in place, just so you know.
Having a separate view for this is a good idea and could be associated with
bookmarks and related. Probably containing a table of the information,
that is selectable, editable?
> 3. Comments
>
> This is very useful: if we could flag difficult segments, it would
> also be nice to be able to add comments to segments. For example I
> label x segment as "no sense" and then write a comment on it (like in
> Word or Writer) "must ask the author what he really meant with this
> sentence", or "the wr 'X' has three possible meanings, all of which
> make sense in this context, which one did he really mean?"
>
> This is very useful not only for oneself but also for other people, as
> sometimes we translate the same text using the same project file.
>
> The challenge here would be to define if comments should be stored in
> the tmx or in a separate file. Maybe if we make a comments folder with
> particular files that store the comments and tell OmegaT+ what segment
> has what comment. This would allow several translators to work on
> different sections of the same text and share their comments folder
> without having to share the .tmx all the time.
This might also be considered as adding annotations to the segments/TMX.
The actual problem with this is that TMX is actually used as the project file
in the first place. What is needed is a different, application specific format
that can handle this and other possible requirements that TMX is not suited
for. Separate file(s) could be used perhaps as an interim measure, but using
TMX as the project file was a bad choice in the first place, done by the legacy
code side things.
A few complexities are involved also, beyond a better format. For one,
allowing user control of which comments/annotations on which segments that are
exported out to TMX requires a new GUI component.
> 4. Something that everybody seems to miss: a more useful glossary.
>
>
> Some glossary entries are not just one word, but a long compound:
>
> English = Spanish
> Birthplace = lugar de nacimiento
> Birthdate = fecha de nacimiento
The glossaries you use can be more than one word already. It uses CSV
format (or TSV). Any number of words, as long as they are between
the commas (or tabs) when viewed as text externally, is okay.
>
> Some translations are even longer sentences. So it would be time
> saving to have an 'add term from glossary' option like wordfast does
> (I think). It would paste the glossary's 100% matching word where the
> cursor is. How difficult is to do this programming-wise? If that's too
> difficult what about having a button next to each word and once you
> push it it adds the term right where the cursor is? Or even better, a
> toolbar in the glossary view with some buttons for adding a particular
> word to the translation view?
This is a bit of work to implement. New GUI component required for it.
But I think it sort of falls in line with some other GUI needs for tables,
so while working on one of these types of components I may be able
the generalize it so it can be reused. Basically, a table with selection,
editing, etc. Like what is visible in the documents view, but with more
features.
> 5. Speaking of toolbars
>
> Would it be difficult to add a toolbar to the whole app for speeding
> up the work? It would have all/some/most of the options found in the
> menus, making it faster to work with this tool. If you are interested
> in this idea, I have a list of the most used actions (gotten from my/
> my colleagues personal experience).
Already a consideration. The remaining problem for me is just to find
appropriate (non-ugly) icons that look okay across Linux, Mac OS X, and
Windows.
Send me the list of actions. We can run over them and see what needs
to go where, sort of thing.
> 6. Editable glossary
>
> What about having a tool for editing the glossary? Sometimes I find
> horrible typos in the glossary, they could even cause the app not to
> show a particular term because it looks too different from the one
> found in the original thanks to the typo, it is annoying having to
> open the file, change the typo, and reload the project. It is also a
> good Idea for the initial phase of translation: term recognition.
> Translator would open OmegaT+, start reading the original and start
> adding the terms from the app itself, it would then create a CSV file
> and paste it somewhere, the they would reload the project and start
> working.
I think this goes along with the GUI table for the glossary terms. It
could just be put into a different mode to display all the terms and
then editing could take place directly.
To create a complete glossary from scratch would be more involved
with matching considerations and so forth.
>
> Right now what you do is just open the file in open office, read,
> select terms, look them up, open notepad/gedit/kwrite/whatever and
> start writing the terms and their equivalent. If we could do this from
> the app itself it would save us time (all that window switching takes
> time, really).
>
> 7. A minor feature
>
> I see that OmegaT+ can launch the specified browser. What about a menu
> entry/shortcut for this? The Internet is one of the translator's most
> useful tools, so it would be nice to be able to do it from the app.
> Likewise, it could prove really useful if you are translating an HTML
> document and what to view it.
This is doable, but we will also have to consider launching other applications
for other document types. Not too difficult.
> Well, that's it. Hope some of this can help you.
Sure. Lots of ideas.
I would suggest that you file your ideas as feature requests on the SourceForge
project page so they will all be remembered, prioritized, and checked off as
they are completed.
Anyway, I will have think these over some more before adding them to the
list of todos for the first 1.0.M3 version. Just consider my comments here
as my first reactions, I may be off a little.
Cheers,
Raymond
Silvermoon
One of the features you are considering for the upcoming version is
adding MT using google translator.
I wanted to comment on this:
First of all I believe this to be unnecessary, since most translators
work with the TM tool while simultaneously browsing the internet for
terminology search. They could also open a MT website on another tab.
Besides, Google translator is actually not that good, and having to
submit sensitive information to GOOGLE itself is a really big problem.
Translators who can actually profit from MT are those working on
scientific or technical translation, since this type of text is easier
for machines to translate (the terms, collocations, and meanings are
more exact, and more predictable), and these guys are also the ones
who more likely to be working for a company. So I think this is not
really necessary the browser is there, there is also systran's demo,
babelfish, and countless MT services, not to mention the offline,
installable MT programs that are way better than googletrans and do
not require you to send any info.
So, I personally think this is an unnecessary feature. I got
dissapointed last week when I downloaded OmegaT's 2.0 stable version
and found out they had included this unnecessary feature instead of
the more critical ones, for example it STILL (this has been happening
from 1.4 if I remember well) has some of the menu entries in ENGLISH
while the locale is Spanish!!! But oh well.
laseray
might
want it, but others don't. There seems to be a dominant
dissatisfaction/dislike
amongst translators for it overall. I have a problem with the way it
was put into
OmegaT recently. There was no consultation with any of the user base
about
putting it in. It was just slapped in there without a thought
concerning possible
legal issues that translators might face if they are submitting
private/sensitive
information that does not belong to them. And no one on that side
seems to have
come up with a definitive answer regarding the situation. It seems
they are content
to let it just dangle there until some problem occurs.
I think there is a way to get some benefit from it, but it requires
better thinking
about protecting the clients data first.
You mentioned offline MT programs. Can you list the ones you are
referring to?
Perhaps there is some possibility that way in the future.
For now this MT thing is off the table (not going into 1.0.M3).
Silvermoon
multitasking)
1. A piece of advice for the development: if it is technologically
possible, please try to make new versions that do not screw up past
projects? This is something I hate about OmegaT, and the main reason
why I am still working with 1.8. Almost every time they release new
version they do something to the segmentation system that causes the
tmx of older projects to change in such a way that the new version
interprets segments differently, thus causing older projects to have
new untraslated segments and a lot of "orphan segments".
I realy hate this because it is really annoying to open your old 8000-
segment project with the lates version only to find out that you have
to redo it by placing a copy of the project.tmx in the tm folder and
translating the whole thing again.
2. Another feature that I forgot: isn't it possible to take the
information in metrics.txt and turn some of those values (particularly
the number of words) into a variable, then ask the user to input their
rate per word, have the app do a simple multiplication: words * rate
and then output the translation's job price and display it in the
metrics pane? We could even go further and design a complex algorithm
which makes a discount based on the number of repetitions. Something
like what this program does http://www.catcount.com/. We could also
work on the wordcount module of the sofware (they call it 'parser'
right?) so that it counts words appropriately, unlike openoffice's.
For the algorithm thing (if we are to make it), we require the help of
other users who are also translators here. We must know exactly how to
handle repetitions, should we take word or segment repoetitions into
account? Should we charge for repeated words? How much? Can somebody
explain SDL Trados' analyze feature? It tells you how many exact and
fuzzy matches there are in both words and segments. What's the
proffesional way of interpreting and charging for this?
Raymond Martin
> Oh, I forgot even more things, sorry (side effects ofbeing busy and
> multitasking)
>
>
> 1. A piece of advice for the development: if it is technologically
> possible, please try to make new versions that do not screw up past
> projects? This is something I hate about OmegaT, and the main reason
> why I am still working with 1.8. Almost every time they release new
> version they do something to the segmentation system that causes the
> tmx of older projects to change in such a way that the new version
> interprets segments differently, thus causing older projects to have
> new untraslated segments and a lot of "orphan segments".
>
> I realy hate this because it is really annoying to open your old 8000-
> segment project with the lates version only to find out that you have
> to redo it by placing a copy of the project.tmx in the tm folder and
> translating the whole thing again.
While I can sympathize with this situation, OmegaT+ is still in flux towards
a stable 1.0 right now. So I cannot make any guarantees at this point. I will
say that I am trying to make it so that when it does finally get to 1.0 there
will be a very low probability of this kind of thing changing. I already had
made a couple of changes that screwed up the segmentation configuration
files for past versions. This was unavoidable though and you'd know why
if you had a look at the mess I am contending with from the legacy code!
Plus there is always the chance that improvements in a particular document
filter will result in different segmentation (e.g., the revamped PO filter). So
it seems to me that at some level this is unavoidable if a filter is to be
improved to operate correctly. The old filter did not work properly and those
segments from using it may be what you have stored in your project file.
Rest assured, I am going to give it some serious thought before it goes
stable.
> 2. Another feature that I forgot: isn't it possible to take the
> information in metrics.txt and turn some of those values (particularly
> the number of words) into a variable, then ask the user to input their
> rate per word, have the app do a simple multiplication: words * rate
> and then output the translation's job price and display it in the
> metrics pane? We could even go further and design a complex algorithm
> which makes a discount based on the number of repetitions. Something
> like what this program does http://www.catcount.com/. We could also
> work on the wordcount module of the sofware (they call it 'parser'
> right?) so that it counts words appropriately, unlike openoffice's.
Many things are possible, this being one of them.
> For the algorithm thing (if we are to make it), we require the help of
> other users who are also translators here. We must know exactly how to
> handle repetitions, should we take word or segment repoetitions into
> account? Should we charge for repeated words? How much? Can somebody
> explain SDL Trados' analyze feature? It tells you how many exact and
> fuzzy matches there are in both words and segments. What's the
> proffesional way of interpreting and charging for this?
You hit the nail on the head. Different programs give different word counts.
There does not seem to be an absolute standard as to how to count them. So
even if implemented it is going to be an approximate amount, or miss perhaps
as far as ones clients are concerned.
FYI, I am not a translator, I don't have any experience or information on SDL
myself concerning this. If anybody does we really need to get at it so a
determination can be made as to its function.
Raymond
Raymond Martin
>
> 1. A piece of advice for the development: if it is technologically
> possible, please try to make new versions that do not screw up past
> projects? This is something I hate about OmegaT, and the main reason
> why I am still working with 1.8. Almost every time they release new
> version they do something to the segmentation system that causes the
> tmx of older projects to change in such a way that the new version
> interprets segments differently, thus causing older projects to have
> new untraslated segments and a lot of "orphan segments".
I should also say that I think you are talking about the addition of new
segmentation rules for a particular language, right?
More up to date rules are better, but you can always go into the segmentation
configuration and remove ones you don't want. Would that not solve part
of your problem?
Raymond
Silvermoon
>You hit the nail on the head. Different programs give different word counts.
>There does not seem to be an absolute standard as to how to count them. So
>even if implemented it is going to be an approximate amount, or miss perhaps
>as far as ones clients are concerned.
>FYI, I am not a translator, I don't have any experience or information on SDL
>myself concerning this. If anybody does we really need to get at it so a
>determination can be made as to its function.
can't do it myself since in my country, translators don't use that
kind of software too often, and the prices are much lower that in
other countries. SDL Trados is a proprietary translation software, but
it is not too popular in my country.
Silvermoon
Open Project
Close Project
Create .tmx files (in the case of the current OmegaT+ code, in the
latest OmegaT versions they removed this: when you press enter it
saves the tmx file. I think omegat+ should follow this example as it
is simpler for most users)
Import source file (like the latest OmegaT. This is something that
this project should also have)
Create translations
Save
Search
Validate Tags
Allow original = translation [an icon that brings up the editing
behavior dialog]
all the actions dealing with inserting/switching matches/original text
(though the shortcut is much faster than using an icon). We could have
them in the toolbar for the sake of completeness.
As for Icons I think you could use a popular gtk icon theme like Tango
or any other iconset used in Linux (in GNOME, to be exact). These
icons are very unknown for most translators as most of them use
Windows (because the proprietary CAT tools are Windows exclusive), and
they will find them nice. Most translators are astonished when I show
them Linux iconthemes.
Having a toolbar would be the first step in the process of becoming an
autonomous fork of the other project.
Contrary to what most translators think, forks are NOT lousy copies of
other people's ideas, they appear to be so at first, but as time
passes they start having features that differentiate from the
'original' project. I have shown this project to some colleagues, and
their reaction is 'Oh, it's a copy of OmegaT's older versions'. I have
been thinking about the reasons and I believe it's because most
translators don't know anything about code (they don't even know it
exists) so they can't tell that the code is different. Another reason
is looks. I think you've been doing a good job with the GUI, if I show
them omegat+ with another theme they do see it as something similar,
but not as a copy.
In short, if features continue to be added and the GUI continues to
change, the problem of it 'failing to differentiate itself' from the
other project will slowly disappear, and the achievement of the
project's goal will be closer.
Raymond Martin
> This is the list of the actions people use most frequently:
>
> Open Project
> Close Project
> Create .tmx files (in the case of the current OmegaT+ code, in the
> latest OmegaT versions they removed this: when you press enter it
> saves the tmx file. I think omegat+ should follow this example as it
> is simpler for most users)
OmegaT is assuming that you always want all the TMX documents
to be generated. Some might, others don't. The TMX that get generated
should be considered as exports from the program, with possible options
that can be set. If it gets taken out (without considering this possibility),
then it will just have to go back in later if more options are added that
need this. Something to think over first here.
> Import source file (like the latest OmegaT. This is something that
> this project should also have)
Yes, the ability to "Add" documents to a project from within it is needed.
FYI, "Import" is just stupid jargon by OmegaT, there is a bunch of it in that
app.
> Create translations
> Save
Unnecessary. The program automatically saves its project TMX when you
exit or generate documents/TMX.
> Search
> Validate Tags
> Allow original = translation [an icon that brings up the editing
> behavior dialog]
> all the actions dealing with inserting/switching matches/original text
> (though the shortcut is much faster than using an icon). We could have
> them in the toolbar for the sake of completeness.
Toolbars are a work in progress at this moment. The dialogs for a number
of things they have are missing, but I am not too inclined to add all of them
yet, until I have a chance to look at other options first. It is just too many
dialogs for little options.
>
> As for Icons I think you could use a popular gtk icon theme like Tango
> or any other iconset used in Linux (in GNOME, to be exact). These
> icons are very unknown for most translators as most of them use
> Windows (because the proprietary CAT tools are Windows exclusive), and
> they will find them nice. Most translators are astonished when I show
> them Linux iconthemes.
For now I will just have to reuse what I have. Not all icon themes are equal
and they don't all seem to be good even within the same theme! Of course,
tastes vary. So it is pretty hard to say what is nice. Some of them look
great, but they don't have icons that correspond to every action needed.
This is part of the problem that I had when looking for the icons that
are in the menus now.
>
> Having a toolbar would be the first step in the process of becoming an
> autonomous fork of the other project.
Autonomous? Not sure what you mean, it is already independently run.
Being a fork sort of means autonomous in this case (not like a branch or
set of patches).
>
> Contrary to what most translators think, forks are NOT lousy copies of
> other people's ideas, they appear to be so at first, but as time
> passes they start having features that differentiate from the
> 'original' project.
Translators actually think that? I would be very surprised to know that
most translators even know what a fork is. Most don't know what Linux or
Java are, so?
> I have shown this project to some colleagues, and
> their reaction is 'Oh, it's a copy of OmegaT's older versions'.
> I have been thinking about the reasons and I believe it's because most
> translators don't know anything about code (they don't even know it
> exists) so they can't tell that the code is different. Another reason
> is looks. I think you've been doing a good job with the GUI, if I show
> them omegat+ with another theme they do see it as something similar,
> but not as a copy.
Do you mean by changing the Look and Feel from the menu?
>
> In short, if features continue to be added and the GUI continues to
> change, the problem of it 'failing to differentiate itself' from the
> other project will slowly disappear, and the achievement of the
> project's goal will be closer.
Sounds nice, but, personally, I am not concerned with it differentiating
itself that much from OmegaT. If I were, I would have named it something else.
It has got most of the guts of OmegaT. The only way for it to really be that
different is to not have those guts. So the aim is not exactly to differentiate.
Actually, failing to differentiate itself from OmegaT does not mean anything to
me. I could just create a totally new program with some or a lot of OmegaT's
guts, but different name, look, etc. And then all those translators would
not have any idea that it was related to OmegaT at all. It would do similar
things or not. It really does not matter though, as far as I am concerned.
The important points for me are reliability, stability, better user interface
that considers ergonomics, useful functionality, blah, blah, blah...
I think focusing on those aspect is differentiating it, if we want to look at
it that way. If some people can't see it that way, then there is an issue in
their eyes and the stuff that is above and behind it a few centimeters.
Cheers,
Raymond
Silvermoon
>OmegaT is assuming that you always want all the TMX documents
>to be generated. Some might, others don't. The TMX that get generated
>should be considered as exports from the program, with possible options
>that can be set. If it gets taken out (without considering this possibility),
>then it will just have to go back in later if more options are added that
>need this. Something to think over first here.
acount, but I don't understand it too well. Could you elaborate a
little more (or give examples)
> Import source file (like the latest OmegaT. This is something that
> this project should also have)
Yes, the ability to "Add" documents to a project from within it is
needed.
FYI, "Import" is just stupid jargon by OmegaT, there is a bunch of it
in that
app.
translation actually. That translators use a term improperly is a big
problem as technical translation involves using terms in the proper
technical context despite the fact that we are no technicians
ourselves (actually I think this is why many translators become too
arrogant with people from other areas as they believe they know what
they are saying, which is not necessarily true)], why is it wrong to
call it "import"? Because the app is not actually transforming/
bringing some foreing code/file into its own format? Can you tell me
more about the stupid jargon you mean, this is very interesting to me
(and also makes me worried that translatorsuse it in the wrong way).
>Unnecessary. The program automatically saves its project TMX when you
>exit or generate documents/TMX.
when I press enter to go to the next segment?
What if there is a problem with the OS (it hangs or something)? or if
there is a problem with the office's electricity and then the program
is unexpectedly interrupted (<= is this the right way of calling it,
or should I say closed?) Will the user lose that information?
>Toolbars are a work in progress at this moment. The dialogs for a number
>of things they have are missing, but I am not too inclined to add all of them
>yet, until I have a chance to look at other options first. It is just too many
>dialogs for little options.
take some time for that than to produce a stable version and then like
4 updates i les than a week because of broken things or other issues.
>For now I will just have to reuse what I have. Not all icon themes are equal
>and they don't all seem to be good even within the same theme! Of course,
>tastes vary. So it is pretty hard to say what is nice. Some of them look
>great, but they don't have icons that correspond to every action needed.
>This is part of the problem that I had when looking for the icons that
>are in the menus now.
need the help of some artists, are there some around?
>Autonomous? Not sure what you mean, it is already independently run.
>Being a fork sort of means autonomous in this case (not like a branch or
>set of patches).
written that???). Not autonomous, I mean that it will add to the
program's ease of use, thus taking a further step away from OmegaT.
>Translators actually think that? I would be very surprised to know that
>most translators even know what a fork is. Most don't know what Linux or
>Java are, so?
have had contact with here. Some of my teachers would even disagree,
but the ones I have talked to here believe so). It's just that they
don't see things as technically as we do. They don't know what Linux
or a fork is, but this is not a necessary condition for thinking what
they think. I show them OpenOffice (not exaclty a fork), they say: "an
ungly copy of Microsoft Office, it doesn't even have tabs", Firefox?
"A weird 'internet' with a lot of options that I don't need. OmegaT?
"Trados is the standard, and what's with those weird codes (the
tags)", OmegaT+? "it's a copy of OmegaT" with the same functions and
even less, Debian? "A weird computer with lots of DOS commands"
Ubuntu? "A copy of Debian that claims to be easy but is still too
complicated"
So, as you can see they don't see forks, or the use of open source
code from one project by another. They recognize forks or even
different projects that do the same thing, therefore look similar as
looking 'too similar, therefore must be copied'.
What I was trying to say is that the more similar the app looks and
feels, the more likely it is to be considered 'a lousy copy'. So, by
using a toolbar, it will look further different and users (who, I
recognize, sound like evil heretics when someone who knows a little of
this topic hears them say something like Linux has 'DOS commands')
will be less biased, they will approach the program and the project,
it will be much easier for them to see that there are differences at
the core's level and to understand that you want it to be called OmegaT
+ because it really has more things, things that perhaps are not very
noticeable for them (hell most people don't even know what the code
does in a program). I believe they failed to see this and assumed that
the name is a lack of creativity, which is supported (according to
them) by the fact that it has few functions that make it appear
different (the ones that do differentiate it being technical and
invisible for normakl users).
Oof, I hope I didn't write something misleading there.
>Do you mean by changing the Look and Feel from the menu?
above.
>Sounds nice, but, personally, I am not concerned with it differentiating
>itself that much from OmegaT. If I were, I would have named it something else.
if the proper tweaks are done. If you are a programmer or computer
engineer, you'll be familiar with Microsoft's smart strategies
regarding this point.
>Actually, failing to differentiate itself from OmegaT does not mean anything to
>me. I could just create a totally new program with some or a lot of OmegaT's
>guts, but different name, look, etc. And then all those translators would
>not have any idea that it was related to OmegaT at all. It would do similar
>things or not. It really does not matter though, as far as I am concerned.
>The important points for me are reliability, stability, better user interface
>that considers ergonomics, useful functionality, blah, blah, blah...
>I think focusing on those aspect is differentiating it, if we want to look at
>it that way. If some people can't see it that way, then there is an issue in
>their eyes and the stuff that is above and behind it a few centimeters.
people see it that way is because they lack the knowledge to
appreciate what you are doing. Don't know how the OmegaT guys see this
project (or even if they are programmers or translators or both), but
normal people fail to see those technical differences and then judge
it as a copy, while what you want to do is improve what they have
done, not compete (right?). I thought you wanted to used OT's code to
creaet a new tool that works more properly and in a more technically
correct and effective fashion (though that could eventually be the
side effect of your work).
OK, I talked too much today, see you.
Raymond Martin
> >OmegaT is assuming that you always want all the TMX documents
> >to be generated. Some might, others don't. The TMX that get generated
> >should be considered as exports from the program, with possible options
> >that can be set. If it gets taken out (without considering this
> > possibility), then it will just have to go back in later if more options
> > are added that need this. Something to think over first here.
>
> Hmmm, this seems to be an interesting point I had not taken into
> acount, but I don't understand it too well. Could you elaborate a
> little more (or give examples)
Basically, TMX is just an import/export format for storing the translations.
Options for exporting (importing) them can include whatever options
are available by the standard. Perhaps you want all the formats you can get,
or one, or a particular option in one, and so forth.
There is no real configuration of this anywhere and now just blob the
generation of the documents and TMX together without any alternatives.
It seems a little shortsighted at first glance. A single generation of
everything would be okay if there are sensible/flexible options somewhere
to turn off/on.
>
> > Import source file (like the latest OmegaT. This is something that
> > this project should also have)
>
> Yes, the ability to "Add" documents to a project from within it is
> needed.
> FYI, "Import" is just stupid jargon by OmegaT, there is a bunch of it
> in that
> app.
>
> I'm interested in these technical details [it has a lot to do with
> translation actually. That translators use a term improperly is a big
> problem as technical translation involves using terms in the proper
> technical context despite the fact that we are no technicians
> ourselves (actually I think this is why many translators become too
> arrogant with people from other areas as they believe they know what
> they are saying, which is not necessarily true)], why is it wrong to
> call it "import"? Because the app is not actually transforming/
> bringing some foreing code/file into its own format? Can you tell me
> more about the stupid jargon you mean, this is very interesting to me
> (and also makes me worried that translatorsuse it in the wrong way).
To find the accepted meaning of import you can just look at other programs.
Importing a format into any of those programs means to convert the
format into something acceptable for the program that it does not really
support. All the so-called imports that OmegaT (OmegaT+) is doing are
supported by document filters for those formats. Thus, they are directly
supported and not imports at all. In OpenOffice.org, you don't import
an ODF or HTML, they are supported. You do import/export PDF (in newer
versions).
In our program of interest here, we are only adding documents into a specific
location (/originals) so that they are opened, parsed, tokenized, and
segmented for use. All this is aided by "native" filters in the app.
Other stupid jargon: file filters, there are no file filters specifically in the
program. They are document filters, documents being files with human
readable text for the purposes of translation. File filter is too generic.
Translators work with documents, to be exact. File filter configuration,
there is no file filter configuration in the program. Again this is document
filtering. Fuzzy matching, as far as text processing goes it does not exist.
Yes, this term is used all over the place in CAT tools, but it is incorrect.
The correct term is either inexact or approximate matching. Just check the
technical literature on string matching (which originates in computational
biology). They never use that term anywhere. It is only a de-facto term that
some commercial CAT tool vendor put out along the way somewhere. Source and
Target, these are incorrect and ubiquitous terms that have nothing to do
directly with translation, but come from computational linguistics and its
roots in computer science. Source and target and blatant terms from things
like C/C++ compilers, completely irrelevant and de-facto. OmegaT
used to use the term "compile" to describe what was being done when
the translations are created. Again an almost complete reference to
computer science. These things are generated. There are more, but I
will shut up now.
> >Unnecessary. The program automatically saves its project TMX when you
> >exit or generate documents/TMX.
>
> Oh, Ok. Good thing, I hadn't noticed. Does it save to the project .tmx
> when I press enter to go to the next segment?
No. There is a periodic generation (about 10 minutes apart) of that if you do
not generate the outputs yourself.
> What if there is a problem with the OS (it hangs or something)? or if
> there is a problem with the office's electricity and then the program
> is unexpectedly interrupted (<= is this the right way of calling it,
> or should I say closed?) Will the user lose that information?
You could loose a certain portion, depending on when you last generated or
it automatically generated for you. A power interruption could happen and
cause many programs to lose data.
>
> >Toolbars are a work in progress at this moment. The dialogs for a number
> >of things they have are missing, but I am not too inclined to add all of
> > them yet, until I have a chance to look at other options first. It is
> > just too many dialogs for little options.
>
> Yes, no problem here. Better to produce a good piece of software and
> take some time for that than to produce a stable version and then like
> 4 updates i les than a week because of broken things or other issues.
Sure. Some toolbars are in my development version now. Should be able
to release with them in, if no problems arise.
> >For now I will just have to reuse what I have. Not all icon themes are
> > equal and they don't all seem to be good even within the same theme! Of
> > course, tastes vary. So it is pretty hard to say what is nice. Some of
> > them look great, but they don't have icons that correspond to every
> > action needed. This is part of the problem that I had when looking for
> > the icons that are in the menus now.
>
> I meant the icons in the toolbar. But now thatyou mention it, maybe we
> need the help of some artists, are there some around?
Good question. It is hard to find something that will look good across at least
the three main operating systems. Stuck with what I have for now until I
make another pass over some of these themes to see what they have updated
or changed.
> >Autonomous? Not sure what you mean, it is already independently run.
> >Being a fork sort of means autonomous in this case (not like a branch or
> >set of patches).
>
> Yeah, wrong word choice there (multitaskin again, how could I have
> written that???). Not autonomous, I mean that it will add to the
> program's ease of use, thus taking a further step away from OmegaT.
I'm trying, but these things have to be weighed against other considerations
concurrently. Trying to think a little ahead before slamming too much in
at once. Slamming will occur, but with a little intelligence, I hope.
What you are saying just makes me think they all have the typical Windows
user mindset. That being the case, it is definitely not a concern. People
who think like that aren't usually the ones that come up with innovative
ideas that they end up embracing down the road!
> Oof, I hope I didn't write something misleading there.
>
> >Do you mean by changing the Look and Feel from the menu?
>
> Yes, with just another theme. This is what I (tried) to explain
> above.
>
> >Sounds nice, but, personally, I am not concerned with it differentiating
> >itself that much from OmegaT. If I were, I would have named it something
> > else. it has got most of the guts of OmegaT. The only way for it to
> > really be that different is to not have those guts. So the aim is not
> > exactly to differentiate.
>
> Not really, it can have exaclty the same guts and still feel brand new
> if the proper tweaks are done. If you are a programmer or computer
> engineer, you'll be familiar with Microsoft's smart strategies
> regarding this point.
Sorry, I do not pay attention to anything MS much.
>
> >Actually, failing to differentiate itself from OmegaT does not mean
> > anything to me. I could just create a totally new program with some or a
> > lot of OmegaT's guts, but different name, look, etc. And then all those
> > translators would not have any idea that it was related to OmegaT at all.
> > It would do similar things or not. It really does not matter though, as
> > far as I am concerned.
> >
> >The important points for me are reliability, stability, better user
> > interface that considers ergonomics, useful functionality, blah, blah,
> > blah...
> >
> >I think focusing on those aspect is differentiating it, if we want to look
> > at it that way. If some people can't see it that way, then there is an
> > issue in their eyes and the stuff that is above and behind it a few
> > centimeters.
>
> Ohhh, I understand you point now. Then, I think the main reason why
> people see it that way is because they lack the knowledge to
> appreciate what you are doing. Don't know how the OmegaT guys see this
> project (or even if they are programmers or translators or both), but
> normal people fail to see those technical differences and then judge
> it as a copy, while what you want to do is improve what they have
> done, not compete (right?). I thought you wanted to used OT's code to
> creaet a new tool that works more properly and in a more technically
> correct and effective fashion (though that could eventually be the
> side effect of your work).
My main point was to make something better that works for the translators
I work with, and let others have it too. It is competition for them that it is
called OmegaT+. As far as using their code to make something better, this has
already been achieved in a few ways. If others don't see it, not much I can do
about that.
Regards,
Raymond