Menu
▾
▴
#675 Quick Translate option for a single file's translation
Quick Translate option for a single file's translation
This RFE is similar to JC's RFE for putting the "project" concept aside, in that it provides a way to speed up the process for translating a single, unique document. I'm not sure if it overlaps with any other RFEs...
JC's RFE:
[#304]
I do not think this RFE is a duplicate of JC's RFE, because I do not propose that the project folder (or any of the settings) be deliberately hidden from the user. My proposal mainly speeds up the translator's work flow (although it would also be helpful to translators who are not skilled at traversing and navigating nested folders and folder trees on their computers).
JC writes:
> The project is a nice thing when processing multiple files is
> necessary, but when only one file is involved, having to go
> through the process of creating a whole project should not
> be necessary and could anyway be hidden from the user.
A feature like this will also help experienced users. I do not regard it as "hiding" something from the user, but as simplifying or speeding up the process for users who don't need all those choices.
The feature would work as follows: Under the "Projects" menu is a new item called "Quick Translate". When the user selects it, he is presented with a dialog that looks very much the same as the Create New Project dialog (except for a few differences, of course).
At the top of the dialog is a new field called "Project name". This field contains the Quick Tranlate project name. By default it can be an incremented number, or the date and time, or (non-ideally) it can be blank so that the user has to fill in some name himself.
All projects created by this method reside in some default location, e.g. "My Documents\OmegaT Quick Translations\", unless the user uses the "Browse" button next to the "Project name" field to navigate to a different folder of his choice.
If the user doesn't use the Browse button but simply types in his preferred name for the project, the project will reside in the default location in a subfolder by that name. If the user types a name that already exists... well, you can decide how you want to handle that (e.g. append a digit, or ask the user, etc).
The five Folder fields that currently exist in the Create New Projects dialog are automatically filled in with relative paths (so that the project's name is not required to be displayed). However, if the user uses the Browse button to select a different folder, then the full path of that folder is shown.
The language selection drop-downs and the segmentation check box are present on this dialog, as they are on the Create New Projects dialog.
At the bottom of the dialog there is a new field called "Source file" with a "Browse" button. The idea is that the user browses to and selects the single source file to be translated. I think the "OK" button on the dialog should be greyed out until a source file is selected.
Also at the bottom of the dialog is a check mark option called "Create Desktop shortcut to..." followed by two radio button options called "Target folder" and "Project folder". This option creates a shortcut on the user's Desktop to either the project's /target/ folder or to the project's root folder. Once the translation is finished, the user can use that shortcut to get to his translated file, even if the project folder is located in some deeply nested location in some obscure sytem-created user folder.
When the user clicks "OK", OmegaT creates a project with the selected parameters, copies the source file into the /source/ folder, and then the translator can start translating.
This feature does hide the project folder in the sense that it is no longer "in the way", but it still exposes the user to the project folder concept whenever he uses the feature, and the user still has to go to the /target/ folder to get his translated file. What the feature doesn't do is that it doesn't shield new users from having to deal with the project folder concept -- it simply makes single file translation less cumbersome.
I don't think this proposed feature should replace the "Import source file" option.
Related
Samuel,
"My proposal mainly speeds up the translator's work flow"
Have you analysed by how much this speeds up the translator's workflow?
How many mouse/keyboard clicks are currently needed, and how many would be needed by your new procedure?
In response to March's comment:
Existing method:
Click Project
Click New
Click in various places to navigate to an appropriate folder
Type in the folder name
Click "Save"
Click "OK"
Click "Import source files"
Click in various places to navigate to an appropriate folder and file
Click "Open"
Click "Close"
Do translation
Minimise
Click in various places to navigate to the project folder
Double-click the target file
Proposed method:
Click Project
Click Quick Translate
Click "Add file" (or suchlike)
Click in various places to navigate to an appropriate folder and file
Click "Open"
Click "Close"
Do translation
Minimise
Double-click Desktop link
Double-click the target file
If you count the steps, it doesn't look like a great timesaver. However, the main timesaver is in navigating the file system. I guess this could also be achieved with just a "create Desktop shortcut" link on the existing "Create New Projects" dialog as well.
"If you count the steps, it doesn't look like a great timesaver."
Thanks, that's what I expected.
"However, the main timesaver is in navigating the file system."
If you only ever create OmegaT projects in the same folder, you don't have to navigate the file system. The location of the last project opened is presented to you by default.
"I guess this could also be achieved with just a "create Desktop shortcut" link on the existing "Create New Projects" dialog as well."
Is OmegaT any different to other applications in this respect? What applications create a shortcut link on the desktop for each newly created file (etc.)?
On the other hand, consider the two – in my view significant – drawbacks of your suggestion:
1. Someone has to write the code, not to mention document it and localize both the UI and the documentation.
2. It introduces a parallel procedure for existing functionality with no significant gain, but by its mere existance presenting a risk of confusion.
Marc wrote:
> Is OmegaT any different to other applications in this respect? What
> applications create a shortcut link on the desktop for each newly
> created file (etc.)?
No, and this is why it is such a good idea for OmT to do it.
Marc wrote:
> 1. Someone has to write the code, not to mention document it and
> localize both the UI and the documentation.
Erm, this is the RFE section, isn't it? :-)
Marc wrote:
> 2. It introduces a parallel procedure for existing functionality with
> no significant gain, but by its mere existance presenting a risk of
> confusion.
Ditto "Import source file".
"No, and this is why it is such a good idea for OmT to do it."
Other applications not doing makes it a good idea for OmT to do it?!
You're not serious, surely? If something is widespread in other applications, you can argue (rightly or wrongly) that it's a) good practice and b) familiar to users.
If it isn't, that doesn't rule out its being worthwhile, but I think a stronger argument for having it is needed than "no one else has it".
"Erm, this is the RFE section, isn't it?" :-)
Of course, but when submitting RFEs, don't you consider how much work they might entail (direct and indirect), and try to weigh that against the perceived benefit?
The RFE section permits comments for a reason. :-)
"Ditto 'Import source file'."
Yes, and I would have preferred that not to implemented. Given that it has, I would suggest in all seriousness that the import operation be followed by a dialog stating "<filename> has been copied to the source file folder of <project>", with an OK button to confirm, to inform the user of what he or she has in fact just done.
Marc wrote:
> Other applications not doing makes it a good idea for OmT to do it?!
> You're not serious, surely? If something is widespread in other
> applications, you can argue (rightly or wrongly) that it's a) good
> practice and b) familiar to users.
Other CAT tools have things in common with OmT but there are also differences. Many modern CAT tools work on the "project folder" principle but OmT is the one that actually encourages the user to interact with the folder and not try to do everything from within the CAT tool, as if through a letterbox.
When I use Trados 2009, WFP, and Idiom, I have no idea where the projects are actually stored on my computer, though I suspect that one could navigate there and do fun stuff with the files.
Creating shortcuts to project files on the Desktop is not uncommon, though. Some programs do it. Just yesterday I installed a video editor that creates shortcuts on the Desktop to open individual projects.
Marc wrote:
> ...when submitting RFEs, don't you consider how much work
> they might entail (direct and indirect), and try to weigh that
> against the perceived benefit?
No. I never (or rarely) consider how much work a feature might entail. Any such consideration would be guesswork, anyway, and those of us who aren't programmers have often guessed incorrectly.
If I had to guess whether adding a Desktop shortcut feature is a lot of work or very little work, my guess would be: very little work. As for the Quick Translate procedure: largely trivial though probably more than one afternoon's work. I'm not joking... but I'm definitely guessing.
> Other CAT tools have things in common with OmT but there are also
> differences. Many modern CAT tools work on the "project folder" principle
This is refreshing to hear. :-)
(It doesn't have to be the "project folder" principle; it can also be the "project file" principle, i.e. a file in which parameters are stored, which to some extent is the case for OmegaT. But I can't see a CAT tool working without some form of project concept, unless it is very inflexible.)
> When I use Trados 2009, WFP, and Idiom, I have no idea where the projects
> are actually stored on my computer, though I suspect that one could
> navigate there and do fun stuff with the files.
Yes, this was one reason why I was unhappy with another tool I tried. I didn't know where everything was, although it's possible that quite a lot of information was in the hidden configuration folder, as is the case with OmegaT.
> Creating shortcuts to project files on the Desktop is not uncommon,
> though. Some programs do it. Just yesterday I installed a video editor
> that creates shortcuts on the Desktop to open individual projects.
That's fair enough then. (Which isn't to say that I'm in favour.)
> No. I never (or rarely) consider how much work a feature might entail.
> Any such consideration would be guesswork, anyway, and those of us who
> aren't programmers have often guessed incorrectly.
Why not bounce it off OmT-dev first? It's a better environment for discussion than the RFE list. (Didier may disagree.)
> If I had to guess whether adding a Desktop shortcut feature is a lot of
> work or very little work, my guess would be: very little work.
Possibly. But the original RFE is much more than just the desktop shortcut feature. Again, unless Didier disagrees, I suggest getting the basic form of the feature together before submitting an RFE.
<<Why not bounce it off OmT-dev first? It's a better environment for
discussion than the RFE list. (Didier may disagree.)>>
On the contrary, RFEs are ill-adapted for discussion.
They're very good to state (and summarize) things, not to discuss them.
<<Again, unless Didier disagrees, I suggest getting the basic form
of the feature together before submitting an RFE.>>
Seconded.
Didier