| Pages in topic: [1 2] > | TransView localization tool Thread poster: Lydie Parisot
|
|---|
I have just inished a localization project where the client had machine translated the UI strings using TransView and needed a proofing. The proofing became a translation mostly and I felt that the software lacked some useful edtting and translation functions.
Has anyone else used TransView for string translation? Iif so how would you evaluate it?
| | | | Lydie Parisot 
France
Local time: 17:30
French to English
+ ...
TOPIC STARTER | Experience with Transview | Sep 19, 2012 |
I can see from the lack of response, this is not a wildly popular tool. I have now been using it for a few months and can share (answer my own question!).
It is a tool directed at software developers and project managers. It allows them to extract strings for localization either DIY, machine translation or by a professional translator.
The UI basically resembles a comma separated file of columns, the first being the default or source strings and the columns to the right... See more I can see from the lack of response, this is not a wildly popular tool. I have now been using it for a few months and can share (answer my own question!).
It is a tool directed at software developers and project managers. It allows them to extract strings for localization either DIY, machine translation or by a professional translator.
The UI basically resembles a comma separated file of columns, the first being the default or source strings and the columns to the rights being for localization into one or more languages across the row.
It has some basic functions like automatic translation or filling in of all repeat strings in the file at once. It can also remove extra spaces between words.
The file extension is proprietary *.trn and I did not find any tools to export or convert that to a more common format.
It is not a true CAT tool in that no memory or glossary are created or saved.
It is not a true text editor as it does not handle text formatting and eliminates all formatting as you work.
As the web site says, it is focused on the developer to help prevent the translator from modifying strings. It works best for short strings of a few words. Translating long and or formatted texts such as paragraphs and lists becomes a translators nightmare.
In my opinion, it is a poor tool only to be used when the *.trn format is requires by the client. And then I would always ask for the source to be in a common format such as .rtf in order to work with or build translation memories. ▲ Collapse
| | | | Samuel Murray
Netherlands
Local time: 17:30
Member (2006)
English to Afrikaans
+ ...
| TRN is the clue | Sep 20, 2012 |
Lydie Parisot wrote:
The file extension is ... *.trn....
That is the clue that we needed to google for "TransView" successfully. The CAT tool is actually called TranSolution, and "TransView" is a component of it, is that right?
http://www.hexadigm.com/FreeDownLoads.aspx
The client will be using the "developer" version of the tool along with Microsoft Visual Studio (.NET) to create the TRN files from the (presumably) RESX files. The translator then uses the "translator" version of the tool to translate the TRN files.
An advantage of this tool is that it allows you to translate UI while seeing how that translation will appear in the UI itself. If I understand correctly, the translator can even resize UI elements to fit the translation.
I haven't seen TRN files, so I can't say for certain whether one can translate TRN files in any usual CAT tool. The "translator" version of the TranSolution tool (called TransView) doesn't seem to offer any glossary or TM functions whatsoever. It's main advantage is that it allows the translator to do stuff that normally he would only be able to do as a programmer, using an expensive program.
Can you get some non-confidential samples of TRN files for us to test?
Samuel
| | | | Lydie Parisot
France
Local time: 17:30
French to English
+ ...
TOPIC STARTER | TransView developper tool | Sep 20, 2012 |
Hi Samuel,
I'll try to answer your questions as you ask them...
Samuel Murray wrote:
That is the clue that we needed to google for "TransView" successfully. The CAT tool is actually called TranSolution, and "TransView" is a component of it, is that right?
Correct, TransSolution is a suite. One tool for translators, the other for Developpers and Programmers.
http://www.hexadigm.com/FreeDownLoads.aspx
The client will be using the "developer" version of the tool along with Microsoft Visual Studio (.NET) to create the TRN files from the (presumably) RESX files. The translator then uses the "translator" version of the tool to translate the TRN files.
An advantage of this tool is that it allows you to translate UI while seeing how that translation will appear in the UI itself. If I understand correctly, the translator can even resize UI elements to fit the translation.
[/quote]
I have only used TransView, the translator's tool. Transview's UI resembles a simple table with rows and columns that can be locked or unlocked to edit. The cells can expand to accommodate text size, but any formatting inside the cell is unstable.
I haven't seen TRN files, so I can't say for certain whether one can translate TRN files in any usual CAT tool.
Unfortunately, I have not found any other program that opens TRN files. It seems to be proprietary.
The "translator" version of the TranSolution tool (called TransView) doesn't seem to offer any glossary or TM functions whatsoever. It's main advantage is that it allows the translator to do stuff that normally he would only be able to do as a programmer, using an expensive program.
I'm not sure what you mean there. The translator's version is built for just the opposite purpose, to prevent the translator from touching anything the programmer put there.
The ONLY tool in the translator version, TransView is a cost-calculator, for quotes per source word. The ONLY editting tools are Copy duplicates, machine translate from online services like GG, delete, copy, paste, cut and find.
Can you get some non-confidential samples of TRN files for us to test?
Samuel
If you download it, it provide a sample TRN file.
Personally, I find the program very limited, and to be of any worth for future projects, must be used in tandem with a CAT tool.
Here's the routinge for that: Open file in TransView/Copy/paste string to CAT/translate/save to TM/copy/paste to TV translation cell/repeat sequence...
Of course if you don't care about keeping a TM or glossary, then for one-offs maybe it fits the purpose.
The main benefit is the complete control it allows the VS programmer over the translation.
| | |
|
|
|
Samuel Murray
Netherlands
Local time: 17:30
Member (2006)
English to Afrikaans
+ ...
| More comments on TransView | Sep 20, 2012 |
[quote]Lydie Parisot wrote:
Unfortunately, I have not found any other program that opens TRN files. It seems to be proprietary. [quote]
I can confirm that it aint a zip file and it aint an ordinary database file either, but it certainly is a binary file.
Samuel wrote:
The "translator" version of the TranSolution tool (called TransView) doesn't seem to offer any glossary or TM functions whatsoever. It's main advantage is that it allows the translator to do stuff that normally he would only be able to do as a programmer, using an expensive program. I'm not sure what you mean there. The translator's version is built for just the opposite purpose, to prevent the translator from touching anything the programmer put there.
What I mean was that the program allows the translator to do the following:
1. Translate the strings, or edit translated strings
2. Resize the UI elements, if necessary
Personally, I find the program very limited, and to be of any worth for future projects, must be used in tandem with a CAT tool. Here's the routinge for that: Open file in TransView/Copy/paste string to CAT/translate/save to TM/copy/paste to TV translation cell/repeat sequence...
I find it sad that one can copy strings in the Form View pane but can't paste or type into it. So all pasting has to be done in the main column view.
It is possible to export a CSV file but you can't import it again. And, the sequence of the strings in the CSV file is different from the sequence of the strings in TransView. And you can't simply sort the strings alphabetically, because TransView's alphabetical sort disregards ampersands, and Excel or Calc's doesn't.
Undo (Ctrl+Z) doesn't work either.
Samuel
[Edited at 2012-09-20 19:49 GMT]
| | | | Lydie Parisot
France
Local time: 17:30
French to English
+ ...
TOPIC STARTER | Experience with Transview | Sep 21, 2012 |
I would be interested in being able to import CSV files that I have previously translated using a CAT tool to TransView in order to export them as TRN for clients requiring this format.
It's editing/translating functions are very rudimentary and inadequate. There are already CAT programs for localizing tags among which are the excellent Poedit or OmegaT programs.
Yes you can put as much text as you want in the cell. That's it.
[Edited at 2012-09-21 21:09 GMT]
| | | | Samuel Murray
Netherlands
Local time: 17:30
Member (2006)
English to Afrikaans
+ ...
| My experiments with TransView | Sep 23, 2012 |
Lydie Parisot wrote:
I would be interested in being able to import CSV files that I have previously translated using a CAT tool to TransView in order to export them as TRN for clients requiring this format.
At first I thought that writing a simple paste script for TransView would be a simple affair, but I've come to the conclusion that it would not be possible (for me) to write a script that can run automatically (i.e. while you have coffee, or do some work on a second computer).
One big problem is that the UI controls are not very responsive, so I can't get a script to click an error message with a high degree of success. Another problem is that TransView performs QA in real time, so you can't move to another segment if TransView detects an error in the current segment, unless you find a way to click around the error messages. And there are many different error messages.
I've been away for the weekend, but I think the best way to deal with pasting in TransView is to use a script that pastes one segment at a time, when the user presses a shortcut. The way this would work, would be as follows:
1. A script is used to extract the segments in a predictable order (e.g. alphabetically).
2. The user translates the extracted text in his favourite CAT tool.
3. Important: the user performs QA on this translation before pasting it into TransView, to minimise error messages.
4. A second script is used to paste the translation back into TransView, one segment at a time.
This means the user has to spend time doing the paste action, but it also means that the user is able to fix any errors reported by TransView immediately.
Performing #1 above has to be scripted, unfortunately, because the strings in the CSV export are not in the same order as in the TransView application itself. So while using the CSV export may be useful (to translate the segments in context, before re-translating the scripted exported text using your TM), it can't be used as the text that is imported (pasted!) back into TransView.
A big problem with TransView is also that the way to select, copy and paste text isn't consistent whichever way you "enter" into a cell. Sometimes Ctrl+A will select the text and sometimes it won't. Sometimes pasting overwrites the text and sometimes it adds to the existing text. And there is no predicable way to ensure that a cursor is present in a cell (without a human looking).
The way error messages behave is also not consistent. Sometimes, if you click "OK" to an error message, the previous keyboard command is executed, but sometimes not. This means a script can't determine which cell has the focus after an error message was clicked through. And all error messages have the SAME window title (arghhh!).
The CSV file will contain string IDs (in the first column), but these string IDs can't be viewed in TransView directly -- you can see the string IDs only when you hover your mouse over the row title, and there is no way a script can grab that, so there is no way for me to use the string IDs as a means to ensure that the right text is pasted in the right place.
Anyway, the user-triggered script should be simple to write... tomorrow or some time.
Samuel
[Edited at 2012-09-23 19:10 GMT]
| | | | Lydie Parisot
France
Local time: 17:30
French to English
+ ...
TOPIC STARTER | Transview = WOP | Sep 24, 2012 |
Samuel,
It was very useful and validating to hear about your experience with TransView. It totally concurs with my own, intuitive experiences. To put it concisely, the program is buggy on top of all it's other quirks.
It more or less tripled the estimated MT post-editing time needed to treat a document. A real earnings killer... Post-editing MT estimates are always a hazardous affair anyway. This program just compounds it.
A big problem with TransVi ... See more Samuel,
It was very useful and validating to hear about your experience with TransView. It totally concurs with my own, intuitive experiences. To put it concisely, the program is buggy on top of all it's other quirks.
It more or less tripled the estimated MT post-editing time needed to treat a document. A real earnings killer... Post-editing MT estimates are always a hazardous affair anyway. This program just compounds it.
A big problem with TransView is also that the way to select, copy and paste text isn't consistent whichever way you "enter" into a cell. Sometimes Ctrl+A will select the text and sometimes it won't. Sometimes pasting overwrites the text and sometimes it adds to the existing text. And there is no predicable way to ensure that a cursor is present in a cell (without a human looking).
LOL, oh yes, how many times would I paste and save only to find it had modified or done something unexpected.
Welcome to TRN World of Pain!
Lydie ▲ Collapse
| | |
|
|
|
| Reply from the author of TranSolution | Sep 25, 2012 |
Hi there,
Woe is me
Actually, this type of response is something to learn from. You are a user after all. I'm the author of TranSolution and I'd like to briefly respond to your comments, which I do appreciate. First, I'm sorry your experience hasn't been a positive one. I'm actually aware of some of your criticisms, but there's far more to the program than meets the eye. There's also (often) good reason w... See more Hi there,
Woe is me
Actually, this type of response is something to learn from. You are a user after all. I'm the author of TranSolution and I'd like to briefly respond to your comments, which I do appreciate. First, I'm sorry your experience hasn't been a positive one. I'm actually aware of some of your criticisms, but there's far more to the program than meets the eye. There's also (often) good reason why certain things were done the way they were (or not), and in some cases, there may just be a lack of familiarity with these issues. Adequately addressing all of them wouldn't be appropriate in this forum however, since the site moderators may not appreciate it. I have to say however, that the program actually does an excellent job overall, with very few bugs ever reported. No, it's not buggy as you stated or I would have been flooded with many complaints. While no program can legitimately claim to be completely bug free, bug reports are actually few and far between. Only one can even be categorized as serious since the program was released. That bug was actually a MSFT bug, and a work-around was already implemented (since they won't fix it). The program has an excellent track record of stability, and it was only released 2 years ago. New programs usually have *far* more bugs. TranSolution is professionally written, and also has a lot of internal error checking that users aren't even aware of.
In any case, you might not expect to hear anything less from the author of a product, extolling its virtues in response to criticism, but this isn't a hollow defense. An objective analysis of the product will support my claim. Many others agree, as I've received a lot of very positive email from many developers telling me how much time and money the program has saved them. It actually does make their job almost effortless. Some have even abandoned some of the larger and well-known translation programs in favor of it. Rather than get into the details here however, and what the program offers that others don't (some significant), I'd be more than happy to take up these issues if you'ld like to email me at [email protected]. And I certainly will address all the issues you raised.
Please note that no program is perfect of course, nor can it be all things to all people, so yes, there are a few things with both the developer's and translator's version that can be improved. And yes, while the translator's program does an effective job most of the time, it does have a few rudimentary features, mainly because the ergonomics of some of its editing capabilities, which are actually controlled by MSFT, can use some improvements. Rest assured though, things are being improved all the time. A separate text editor is even being looked at that you could pop up over a cell and enlarge it, which would be more user friendly should you need it (for long strings in particular). Nevertheless, looking at the big picture, the benefits of TranSolution far outweigh any existing issues. I'll explain why, and will try to help you with the issues you have raised if you'ld like to contact me. Rest assured, if there are any problems, they will be addressed. Improving the program's ergonomics and adding new features is on-going all the time. ▲ Collapse
| | | | Samuel Murray
Netherlands
Local time: 17:30
Member (2006)
English to Afrikaans
+ ...
jeff2 wrote:
Actually, this type of response is something to learn from. You are a user after all. I'm the author of TranSolution and I'd like to briefly respond to your comments, which I do appreciate.
Allow me to jump right in and sketch two scenarios for you:
Scenario 1:
The programmer gets a translator, offers him 20c per word, and gives him 3 days to translate 3000 words in TransView.
Scenario 2:
The programmer hires an agency (Agency A), offers them 20c per word, and gives them 3 days to translate 3000 words. Agency A then contacts a regional agency (Agency B), offers them 14c per word, and gives them 2 days to translate 3000 words. Agency B then contacts the translator, offers him 8c per word, and gives him 1 day to translate 3000 words.
The first translator finds TransView incredibly useful, because it allows him to do all the stuff that TransView can do. He doesn't have to be fast. The second translator finds TransView awful, because it restricts him from optimising his work, which would enable him to translate both fast and accurately, despite the short period of time.
The second translator has worked for this type of client before, and has learnt to ensure high quality and consistency despite high speeds, by learning how to use his CAT tool most efficiently. In fact, he is so confident that using the CAT tool will enable him to complete the job on time that he is willing to employ cumbersome workarounds with TransView (such as copying and pasting the translations), and because of the extra time it takes to perform these workarounds, he probably won't even notice any of the other features of TransView that programmers and translators from the first scenario find so exciting.
If you want to get more praise from translators of the second kind, you need to add the following features to your program:
1. Reliable export and import of content, so that the translator can process the content in his favourite translation program. I would recommend something like Excel, tab-delimited, or key=value, instead of the current CSV export, because CSV has many dialects and not all CSV-capable programs can read it reliably or save it reliably.
2. Post-translation QA, instead of (or in addition to) real-time QA. At present, TransView warns the translator immediately if he makes an error (e.g. duplicate accelerator, doubled accelerator, absense of accelerator), but what would be equally nice would be if TransView can simply mark rows that have errors in them in red, so that the translator can fix those errors afterwards.
Many others agree, as I've received a lot of very positive email from many developers telling me how much time and money the program has saved them. It actually does make their job almost effortless.
TransView certainly has obvious benefits. I'm praticularly impressed by the fact that it allows translators to edit the dialogs, and that it shows translators the strings in context. These things are often lacking in other tools, and translators of software often have to go through multiple rounds of checking to iron out problems related to not having seen context and not being able to fix truncation issues etc immediately. I suspect a large benefit for developers is that TransView ensures that some of the issues that developers often have to deal with after the translation has been done, are now taken care of by the translator (a certain amount of QA).
A separate text editor is even being looked at that you could pop up over a cell and enlarge it, which would be more user friendly should you need it (for long strings in particular).
An edit field like the one you describe would be more cumbersome for translators of the second type, because it would require additional mouse clicks to get to the text and to move through segments. Not having to use the mouse is quite important for me personally, because my arms and wrists get tired a lot quicker if I have to do precision mouse clicking than if I could simply press a keyboard shortcut without even looking at the keyboard.
Samuel
| | | |
Hi Samuel,
Thanks for the feedback, and the positive comments (in addition to the constructive criticism). I hear you loud and clear but there are some counter-arguments. Post-translation QA for instance is error-prone and cumbersome in its own right. If a translator neglects to add the "{0}" to some string for instance, in spite of validation, there's a very good chance it won't be detected until the client developer's program crashes on a customer's machine. Either that or additio... See more Hi Samuel,
Thanks for the feedback, and the positive comments (in addition to the constructive criticism). I hear you loud and clear but there are some counter-arguments. Post-translation QA for instance is error-prone and cumbersome in its own right. If a translator neglects to add the "{0}" to some string for instance, in spite of validation, there's a very good chance it won't be detected until the client developer's program crashes on a customer's machine. Either that or additional checks would have to be implemented to warn the developers if the ".trn" file is returned with errors (which it already does for some situations, but not the types of situations that are currently prevented because TransView doesn't allow them in the first place). The extra work also adds more overhead to the program (never a good idea), and potentially more issues for all parties to deal with (which is best avoided). Relying on someone to complete post-QA validation isn't normally appropriate for any program IMHO (usually). In theory, why should a program allow invalid data to be entered at all, in this case an invalid string, only to be corrected later. It shouldn't normally (usually), which is why the program does it in real time. Only when fields need to be cross-referenced against other fields, should certain types of error-checking be deferred, but that type of validation isn't usually present (or prevalent) in a translation program (so I won't get into the details here). Add to the situation the fact that someone might import data with errors, then export it again with or without errors (depending on whether validation was conducted yet), and then (possibly) add the program's existing "File -> Export" feature to the mix (which creates other ".trn" files with a subset of languages for parceling out the work to other translators, which they may in turn export using the Excel-type feature you're requesting), it's possible that certain subtle scenarios may develop that could introduce errors previously thought eliminated (unless a detailed analysis of all the permutations that might occur is conducted, which may be non-trivial to do or even handle, should any problems actually be discovered). The cleanest and most stable scenario is to simply prevent invalid data in the first place (whenever possible). In this case, simply rejecting any invalid data during an import would do the job (allowing valid data only), after which it would need to be corrected before trying import again (or corrected on-the-fly where suitable, but again, all this leads to more complications).
In any case, the main issues driving this post seem to be the following:
1) Improving some of the editing capabilities
2) Lack of CAT
The first issue isn't that significant in most cases (IMHO), since it's normally just a simple matter of entering the translated strings and you're done. Most programming strings are (usually) very simple, relatively short (typically), and usually don't require any special formatting, even if they are long (not including things like "{0}" or HTML issues). Formatting within the string itself is actually highly brittle, and programmers who know better won't normally do this. If some things need to be improved, such as any pasting issue you may have encountered, that can be dealt with. I'm aware of a few issues myself, usually because of how MSFT did things. The program isn't inherently buggy because of these issues however, even if a previously unreported bug was actually discovered (don't know if that's even the case). It doesn't make the program inherently buggy or unstable - it's not. It may just need a small adjustment, quick fix, or some enhancement to improve things. In some cases, there may be no problem at all, just a lack of understanding that simply needs to be cleared up. In most cases though, entering the strings in the grid is routine and a non-issue. A 3rd-party app isn't required for this.
As for lack of CAT, and the emphasis on exporting and importing, I have considered CAT, but since the program is still relatively new, there simply hasn't been enough time to pursue every feature yet (though it already does a very good job). Exporting/Importing to another format therefore wouldn't be necessary if it had the feature in the first place (with a trivial learning curve). Ok, it doesn't currently, and that may be the point, but the type of exporting/importing you're referring to is error-prone. Mucking around with ".resx" issues, string keys, etc., is low-level and inherently unsafe. It's not something anyone should normally be doing. A translation program (or any other program) should remove all that drudgery and potential for problems. A dedicated program will also deal with issues that a general-purpose program like Excel can't. Even when relying on another (dedicated) translation program to do the work (because the translator already knows it), it may not (and this case probably doesn't) deal with some of the specific issues that TranSolution does (having to do with Visual Studio for instance, and/or other possible issues). Exporting and importing would also be problematic anyway (for TranSolution), since it has to enforce certain rules or programmer options, such as preventing existing strings from being updated if they requested that. Certain things that it tracks or may need to track in the future could also be lost, compromised or rendered impossible to implement if external translations were allowed. In most cases though, it might simply be unwieldy, difficult or ergonomically complicated to deal with some of these issues (not impossible usually). There are other issues as well, such as dealing with conflicts between the imported strings and those found in the ".trn" file, if changes were made to the ".trn" file that conflict with the imported strings (for instance). This may be rare but the program has to deal with it because if it can occur, it eventually will.
The bottom line is that there are potentially complicated issues to deal with when you start allowing someone to modify your program's data outside its normal environment, and trying to deal with those issues during a bulk import (even if ultimately doable). There's also the matter of how it stores its data. TranSolution's data is in fact stored in a proprietary format that's hierarchical (for good reason), so there aren't just simple keys to export. It's more complicated than that, and since there's no industry standard it could have followed for storing this data, I created a standard. No 3rd-party program will natively understand that standard, which is why a ".trn" file can't be used in other programs . Relying on Excel or some other high-level program to look at the raw data is an accident waiting to happen, even if some simple key were manufactured to deal with this. So the real answer to the situation is to not rely on a 3rd-party program, but to implement a CAT feature. Of all the issues discussed, where does this one rank in your opinion, considering the nature of the program, which is to handle relatively short (programming) strings (usually), and not huge bodies of text normally (or perhaps none of this matters).
As for popping up an editor, don't worry, if this feature does make it in, it will be easy to use (either automatically activated when you start editing, possibly based on some program setting you can control, or by double clicking the cell, or through one or more hot keys - all ideas are on the table).
Finally, the benefits the program offers developers is immediate and occurs on several fronts. First, the developer's version integrates into Visual Studio itself. It's an add-in for Visual Studio and programmers simply click "Tools -> Translate -> Outgoing" from the existing Visual Studio menu (the TranSolution install program adds the "Translate" item to that menu). This creates the ".trn" file directly from the ".resx" files in their program, and "Tools -> Translate -> Incoming" is later used to import the (translated) ".trn" file back in (updating their ".resx" files and possibly other future files accordingly). The process is dead simple for the developer. During outgoing translation, the program will also notify them of strings that have changed, and whose translations therefore need updating (which are then highlighted in red in TransView or cleared entirely - it's their choice). It also takes care of many different issues, such as warning the programmer if, say they, changed the string "Surname" to "Last Name" in their program *after* sending the former out for translation. They'll be notified of this during incoming translation, and can either accept the original outgoing string ("Surname") or (usually) retain the existing (updated) string ("Last Name"). They can also (optionally) prevent the translator from modifying strings that have already been translated, prevent them from using the "Translate from the web" feature (not enforceable if externally done via the export mechanism we've been discussing, which is another strike against it), etc. Compared to other techniques I've looked at, this system makes their job extremely easy (almost no work at all). A lack of some features, or some enhancements to others, will improve the package over time (including the translator's version), but even in its current state, it's already a very effective program.
Well, as I sometimes say to customers, brevity isn't one of my virtues, but that's my statement to the jury
[Edited at 2012-09-25 15:43 GMT]
[Edited at 2012-09-26 02:12 GMT] ▲ Collapse
| | | | Samuel Murray
Netherlands
Local time: 17:30
Member (2006)
English to Afrikaans
+ ...
G'day Jeff
The reason for post-translation QA is simply to allow importing.
I understand the objection that post-translation QA might lead to non-compliant TRN files being delivered to the client. One solution to that is to force the translator to be aware of the errors, e.g. by refusing to perform the final export if there are errors, or by writing a list of errors to a log file (to be delivered to the client along with the TRN file). If it is easy for a translator t... See more G'day Jeff
The reason for post-translation QA is simply to allow importing.
I understand the objection that post-translation QA might lead to non-compliant TRN files being delivered to the client. One solution to that is to force the translator to be aware of the errors, e.g. by refusing to perform the final export if there are errors, or by writing a list of errors to a log file (to be delivered to the client along with the TRN file). If it is easy for a translator to jump to the next error, and to mark an error as false positive, the client can reasonably expect the translator to deliver the TRN file error-free.
One solution mentioned by you is to simply refuse to import a non-compliant file, but that will only result in frustration, if the translator is unable to figure out what is wrong with his file, and this will lead to more support requests to the developer (e.g. "it doesn't work, so you must help me"). TransView itself is the best tool to show the translator what the errors are. A smart translator may have been able to avoid most of those problems already, but not all translators who use CAT tools have extensive knowledge of such QA processes in their own tools.
Of all the potential problems with immediate QA, the biggest one that I can think of is that it forces the translator to perform two quite different tasks at the same time. The translator is fastest if he can focus on one type of task. QA messages break the translator's rhythm. That said, immediate QA can also teach a translator to work more carefully. In my own CAT tool, I have real-time QA enabled, but I also know from experience that if the error messages come thick and fast, it is easy to forget about it and just click through them, to get back to the rhythm.
If some things need to be improved, such as any pasting issue you may have encountered, that can be dealt with.
Keep in mind that the bulk of my post to the OP related to the suitability of the program for scripted pasting, so that isn't something that a normal user would have to worry about. I did not find the editing features to be disfunctional in any way that matters to translators who translate directly in TransView (except perhaps for the lack of undo/redo, and lack of copy-source).
Exporting and importing would also be problematic anyway (for TranSolution), since it has to enforce certain rules or programmer options, such as preventing existing strings from being updated if they requested that. Certain things that it tracks or may need to track in the future could also be lost, compromised or rendered impossible to implement if external translations were allowed.
I know what you mean, since I have worked on projects where tools had problems with importing features that were poorly designed or assumed one scenario which wasn't always the case (one terror that comes to mind immediately is Pootle).
So the real answer to the situation is to not rely on a 3rd-party program, but to implement a CAT feature. Of all the issues discussed, where does this one rank in your opinion, considering the nature of the program, which is to handle relatively short (programming) strings (usually), and not huge bodies of text normally (or perhaps none of this matters)?
I'm afraid my opinion on that matter is not relevant, because even if the tool had limited CAT features (and if I were asked to translate with it), I would still try to use my own CAT tool. So I don't think you should allow my comments to carry too much weight except to give you another point of view. Which CAT features are important depend also on the language and on whether there is one or more translators and whether the project is translated from scratch of updated.
Compared to other techniques I've looked at, this system makes their job extremely easy (almost no work at all). A lack of some features, or some enhancements to others, will improve the package over time (including the translator's version), but even in its current state, it's already a very effective program.
Yes, I got the impression that the program is quite useful for developers.
Samuel ▲ Collapse
| | |
|
|
|
Samuel Murray
Netherlands
Local time: 17:30
Member (2006)
English to Afrikaans
+ ...
| My TranzVoo script, for TransView | Sep 25, 2012 |
G'day Lydie and anyone reading this thread
I've created a small tool that you may find useful with TransView. To use it, first save the TRN file as a CSV file, then translate (or proofread) it, then save it as a text file, and then use my TranzVoo script to paste the translations.
http://wikisend.com/download/422086/TranzVoo.zip
Here is the readme file:
TranzVoo v1
2012, Samuel Murray
TranzVoo is used for pasting text from a mini-TM into TransView. You can customise it for other programs too.
How it works: When you press the shortcut key (Ctrl+Num-plus), TranzVoo moves one cell to the left, copies its content, looks up that content in your mini-TM, moves back one cell to the right, and pastes the translation. The other shortcut key does a similar thing but doesn't paste the text.
TranzVoo assumes the mini-TM is named "mini-TM.txt" and is a UTF8Y text file with two columns (source text, tab, target text). TranzVoo can't handle multiple translations for identical source texts.
To create the mini-TM, save your TRN file as a CSV file, and open it in OpenOffice.org/LibreOffice Calc. Then use that to create a two-column file with the source text in the first column, and a second column where you would type your translation. Translate the file (e.g. in MS Word or your favourite CAT tool), and save it as "mini-TM.txt" for use in TranzVoo.
To use TransVoo in TransView, hide all columns except the current language column (so that two columns remain). To do that, right-click any cell in your language column and select "Hide all columns except". Then, in TransView, move to the cell where you want to insert a translation, and press the shortcut key.
The mini-TM in the "sample" folder is a test TM in Afrikaans that works with the sample TRN file that ships with TranzVoo. It deliberately contains errors, so that you can see that you should fix them when they occur.
Let me know if you find this useful.
PS. I forgot to add: the mini-TM must be in the same folder as the script.
Samuel
[Edited at 2012-09-25 20:40 GMT]
| | | | Lydie Parisot
France
Local time: 17:30
French to English
+ ...
TOPIC STARTER | depending on your viewpoint | Sep 26, 2012 |
@jeff
Thanks for your input. As you yourself state:
"I've received a lot of very positive email from many developers telling me how much time and money the program has saved them.·
which simply confirms what I have found through experience and from exploring your own website product information. The program is directed to developers and I have no doubt it they praise it.
There already exist good tag and string ... See more @jeff
Thanks for your input. As you yourself state:
"I've received a lot of very positive email from many developers telling me how much time and money the program has saved them.·
which simply confirms what I have found through experience and from exploring your own website product information. The program is directed to developers and I have no doubt it they praise it.
There already exist good tag and string editors widely used by translators in the field.
Why not give developers have the option of exporting the file to known file formats for processing by translators through a CAT tool of their choice?
Lydie ▲ Collapse
| | | | Lydie Parisot
France
Local time: 17:30
French to English
+ ...
TOPIC STARTER | TranzVoo. for Transview | Sep 26, 2012 |
Samuel,
Great concept.
I have downloaded the TranzVoo. I will give it a try when I get a chance and let you know.
Nice work!
Lydie
| | | | | Pages in topic: [1 2] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » TransView localization tool | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
| | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
