| Pagine: < [1 2] | TransView localization tool Iniziatore argomento: Lydie Parisot
|
|---|
Hi Lydie,
In response to this post note that:
1) I'm now working on improving the editing capabilities of the grid. There are a few flaky issues that I've always known about and those will be eliminated. These were primarily due to default MSFT behaviour which is tricky to overrride (so that it works more naturally). It's always been on my todo list but because there were no previous complaints, it was closer to the bottom of the list. When all is done, "Ctrl + A" will ... See more Hi Lydie,
In response to this post note that:
1) I'm now working on improving the editing capabilities of the grid. There are a few flaky issues that I've always known about and those will be eliminated. These were primarily due to default MSFT behaviour which is tricky to overrride (so that it works more naturally). It's always been on my todo list but because there were no previous complaints, it was closer to the bottom of the list. When all is done, "Ctrl + A" will work normally again (that one was actually my fault - mea culpa). Undo/Redo will also work but only while you're actually editing a cell's text (meaning that once you end edit mode for a given cell, you can no longer undo/redo because supporting that when edit mode isn't active is enormously difficult). Note that while editing your text, undo/redo doesn't work in the current version because MSFT doesn't support it out-of-the-box (believe it or not). I'm now building a work-around that will support it. Lastly, while editing your text, you'll be able to navigate through the text without jumping out of the cell when you press the up or down cursor keys (which sometimes occurs because again, it's the default MSFT behavior - long story). In the next release it won't do that anymore. I've always found it very annoying and so do many others probably. If you would be interested in assisting me, I'd also like some feedback on a new pop editor I'm now experimenting with. If you press "Ctrl + F2" while editing a cell (this will be new), a window will popup with the cell's existing text and you can resize that window to your liking (taking up the entire screen if you want). You can therefore edit your text in that window instead of the cell and when you click OK, it will populate the cell from that window. It's really just a full-sized editor but some may prefer it. I'm also investigating adding a sizing grip to the bottom right-hand corner of a cell's window. That's just the small square with diagonal lines that you see on some windows in general (such as the one you see in the proz window when you're typing responses in this forum). This is harder to implement however because of possible MSFT limitations, so there are no guarantees just yet. In any case, I need some feedback to see if these features will actually be useful (the popup in particular). Any interest? It won't take much time and I can email you the beta versions when they're done. You just need to comment on whether you like it or not (or how you would improve it). If there's anything else you want in the editor, now's a good time to let me know. Depending on the request, I may implement it in the next release if it's widely usable (and not too complicated to implement in the short term). You can email me at [email protected] if you're interested. Thanks.
2) As for CAT, this is a much more complicated issue as per my previous posts (if you had the patience to read them). I will look into it though.
Finally, note that the program is not just for the developer. While they're the ones who purchase it, and I spent a lot of time designing it to make their life easy, it has to be easy for the translator as well. I think it mostly is, but will implement improvements to make it even easier. The CAT feature will take longer to investigate, and the timing of that is something I can't address right now, but I welcome any other suggestions. I do listen to my customers, including their translators. Thanks for bringing these issues to my attention.
[Edited at 2012-09-26 15:31 GMT]
[Edited at 2012-09-26 15:32 GMT] ▲ Collapse
| | | |
>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
So much for user-friendly software, but it's not what I meant fortunately (no respectable developer would ever commit such blasphemy ). They would be informed of all errors in some user-friendly way, and given the optio... See more >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
So much for user-friendly software, but it's not what I meant fortunately (no respectable developer would ever commit such blasphemy). They would be informed of all errors in some user-friendly way, and given the option to either cancel outright (rolling back all changes, if any), or continue importing valid data only. They would have to correct the invalid data afterwards but they can then run the import feature again. Only data that wasn't already previously imported or which has changed will then be imported. This iterative process can continue if necessary until all data is successfully imported. Users will always be properly informed of any problems with their data though.
>Keep in mind that the bulk of my post to the OP related to the suitability of the program 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).
Good to hear. Note that Undo/Redo situation was explained in my last post to Lydie (improvements coming). Not sure what you mean by "copy-source" though (?).
>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.
Understood.
>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.
Can you elaborate? Not sure I quite follow it, but if you mean typing directly on the form itself, that's not natively supported by MSFT (even developers can't do that in Visual Studio). It certainly could be supported of course, if someone wanted to manually program it, and I have considered it, but it's a lower priority right now (I was actually "sad" myself when I discovered it wasn't natively supported). Note that the "Form View" feature was actually extremely difficult because of so many MSFT technical issues. The type of improvements I would like to see required far more work than time allowed during the initial development. It certainly does the job, and most are probably happy with it, but just a few "minor" changes could significantly improve things. Those "minor" changes turn out to be more complicated than they appear however, again (common theme), because some things just aren't supported out-of-the-box by MSFT (so there's just no time to do it all at once - it's coming though). ▲ Collapse
| | | | Samuel Murray 
Paesi Bassi
Local time: 03:32
Membro (2006)
Da Inglese a Afrikaans
+ ...
jeff2 wrote:
Samuel wrote:
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...
No respectable developer would ever commit such blasphemy...
Sadly, I've seen it, even in projects where I otherwise have great respect for the developers. Some programmers are religious about formats, and believe it is the user's own fault if he tries to open a non-compliant format and fails. I'm happy that you're not such a one.
Not sure what you mean by "copy-source" though (?).
I mean a keyboard shortcut that will copy the source text into the target field.
It is useful if the source text contains elements that would otherwise take long to type manually. It is sometimes faster to simply use the source text as a base and make changes to it, instead of typing the whole translation from scratch.
Some translators prefer to translate by overtyping the original, and some prefer to translate by typing out everything from scratch. The option to manually "copy source" will help the first group of translators also.
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.
Can you elaborate?
I had another look, and it would appear that I had made a mistake when I checked that feature. I must have selected the default language before I launched the form view. I now see that if I select the target language before launching the form view, I can actually type in the translations.
Still, I can't get from the source text to the target text field without the mouse. Pressing right arrow or tab just expands the item but does not place my cursor in the translation field where I'm supposed to type.
I also notice that undo (Ctrl+Z) does not work for moving around elements in the form. This might be useful for translators who have moved an item but then decide that they want it where it was originally.
The form view editing can be improved by making "Cancel" the default option when the translator tries to exit the form view without saving. Otherwise the translator might lose work if he didn't realise that pressing "OK" means "Okay, lose my work".
==
jeff2 wrote:
When all is done, "Ctrl + A" will work normally again (that one was actually my fault - mea culpa).
If I had to design an editing tool I'd be inclined to keep the normal editing shortcuts for editing features. This would mean keeping Ctrl+A for "select all", regardless of focus. You have keyboard shortcuts for almost all features, but I don't think it is necessary to have a keyboard shortcut for a feature that will only be used rarely. For example, do you really think a user would want to hide or unhide columns more than once or twice in a sitting? Anyway, just a thought.
Undo/Redo will also work but only while you're actually editing a cell's text (meaning that once you end edit mode for a given cell, you can no longer undo/redo because supporting that when edit mode isn't active is enormously difficult).
This was actually what I meant, but I understand that it may be an unrealistic expectation. After all, undo/redo doesn't work that way in Excel either. I guess I'm just spoilt with programs in which undo/redo works everywhere, and with histories of thousands of steps.
I'd also like some feedback on a new pop editor I'm now experimenting with. ... I'm also investigating adding a sizing grip to the bottom right-hand corner of a cell's window.
I'm sure these would be very useful, if you can't make cells that always expand vertically to fit the text or make the cells expand automatically while the user types.
As for CAT, this is a much more complicated issue as per my previous posts (if you had the patience to read them). I will look into it though.
It is hard to discover what CAT-like things are wanted or favoured by which translators, because different translators use different CAT features frequently. If you do go that route, then my humble suggestion would be to have at least a docked pane (or three, actually) that displays results from three types of queries (manual or automatic). They are:
1. Glossary pane: The user supplies a simple tab-delimited glossary, and if a word in the current cell's source text matches any lines in the glossary, they are displayed in the glossary pane. This lookup is automatic and is done whenever the user moves to another cell. Or, if the pane also supports matching of text in the target text, the lookup can be done in real time, whenever the user types a word. It would be great if the user can edit the glossary at any time and TransView would detect the updated glossary instantly.
2. TM pane: The user supplies a TM in a format you support, and whenever the current cell's whole source text is similar to any line in the TM, it is displayed in the TM pane, along with a percentage to indicate similarity. This lookup is also automatic.
2.1 A more comprehensive feature would highlight differences between the TM match and the current source text.
2.2 An even more expanded feature would allow translators to copy/paste one of the matches into the current cell using a shortcut (e.g. Ctrl+1, for match #1, etc), so that they don't have to type it manually or copy/paste it by hand.
2.3 Even better would be that whenever a translator translates a cell and validates it or moves to the next one, the translation is added to his TM. This would be highly preferable, in fact.
3. Concordance pane: This is basically like a "Find" function, except that the function does not jump to the next found instance, but displays all found items in a report (i.e. the concordance pane). This allows the translator to manually do a search for a word or phrase (source or target text) and see how that word was used elsewhere in the current project.
These three CAT items would IMO be the most basic to have and would be incredibly useful for translators who wish to use CAT-like features. I'm no programmer, but it seems to me that they basically involve certain types of searches, with simple results output into docked panes.
Samuel
[Edited at 2012-09-26 21:26 GMT]
| | | |
< Sadly, I've seen it, even in projects where I otherwise have great respect for the developers. Some programmers are religious about formats, and believe it is the user's own fault if he tries to open a non-compliant format and fails. I'm happy that you're not such a one.
I definitely don't work that way. Unfortunately, far too many programmers do (a large majorty in fact, based on my experience).
< I mean a keyboard shortcut that will copy t... See more < Sadly, I've seen it, even in projects where I otherwise have great respect for the developers. Some programmers are religious about formats, and believe it is the user's own fault if he tries to open a non-compliant format and fails. I'm happy that you're not such a one.
I definitely don't work that way. Unfortunately, far too many programmers do (a large majorty in fact, based on my experience).
< I mean a keyboard shortcut that will copy the source text into the target field.
Nobody's ever requested it but it's a good idea and simple enough. Look for it soon (possibly next release)
< Still, I can't get from the source text to the target text field without the mouse. Pressing right arrow or tab just expands the item but does not place my cursor in the translation field where I'm supposed to type. I also notice that undo (Ctrl+Z) does not work for moving around elements in the form. This might be useful for translators who have moved an item but then decide that they want it where it was originally.
There's a tortured history behind this and other similar issues. Believe me, I'm well aware of it. Short story is that the underlying MSFT technology which controls some of the things in the program (including these particular issues) isn't as user-friendly as it sometimes should be. To make it so would have required a lot more work and the program already took a long time to write. There was no good choice available at the time so improving some of these "little" issues had to be deferred. I actually find some of the decisions MSFT makes bewildering. They often produce fantastic technology for developers, but far too often they leave it up to them to provide the final polish. Unfortunately, while the underlying technology is often very solid (which they deserve great credit for), the surface is sometimes so rough that shining it up requires an industrial-strength effort. That's the case here, and with most of the other "small" issues you'll encounter in the program. It wasn't a lack of attention to detail. It was simply an ordeal trying to get things to work as well as they (hopefully) already do (for the most part). While the program usually works very well, I am aware of most of the ergonomic issues you and Lydie have raised and they're all being improved on a regular basis (subject to what can be reasonably done based on the limitations of MSFT's technology and other issues).
< The form view editing can be improved by making "Cancel" the default option when the translator tries to exit the form view without saving. Otherwise the translator might lose work if he didn't realise that pressing "OK" means "Okay, lose my work"
Not sure I follow this one. "OK" always saves all changes. If you try to cancel however, using any means ("Cancel" button, "x" on the upper-right-hand corner, "Alt + F4"), and any changes were made, the program will warn the user. If no changes were made, it will exit with no questions asked. I just did a quick sanity check and it works, but I did notice to my great surprise, that there's one scenario that doesn't work (though it should). If you make a *single* change only, and then immediately try to exit specifically using "Alt + F4" (but only if you haven't vacated the cell), it will exit without saving your change. Based on a quick (internal) check I just did, it appears to be a MSFT bug. Their system isn't informing the program that the text was changed from its original value, as it's normally supposed to do, and always does if you try to exit any other way. I'll have to investigate this immediately.
< This was actually what I meant, but I understand that it may be an unrealistic expectation. After all, undo/redo doesn't work that way in Excel either. I guess I'm just spoilt with programs in which undo/redo works everywhere, and with histories of thousands of steps.
I completely agree that it's now 2012, and undo/redo should be universally supported in most environments (for most mainstream scenarios anyway). As mentioned in a previous post, you'll be able to undo/redo any text changes in the next release, but only while you're actually making changes to the text in "edit mode". After edit mode ends, you can no longer undo it. Supporting that is just too difficult. Note that in the current release, undo/redo isn't support because (yet again), MSFT's underyling "text box" doesn't support it. I just recently finished manually re-coding things so that it does support it. It wasn't initially done because of the larger effort required, but always my intention to do so (finally done).
< If I had to design an editing tool I'd be inclined to keep the normal editing shortcuts for editing features. This would mean keeping Ctrl+A for "select all", regardless of focus. You have keyboard shortcuts for almost all features, but I don't think it is necessary to have a keyboard shortcut for a feature that will only be used rarely. For example, do you really think a user would want to hide or unhide columns more than once or twice in a sitting? Anyway, just a thought.
You're certainly right, but it was done this way because I'm a believer in keyboard shortcuts. I rarely use my own mouse for anything (it's far less efficient for most things), and for those who want to use the keyboard, it's there, even if rarely used. "Ctrl + A" was simply a bad choice (a mistake), and the issue with "select all" just wasn't considered when it was originally chosen (juggling too many shortcut issues at the time). I've decided to replace it entirely in the next release, possibly with "Ctrl + 1" at this point (the "1" seems to have a nice relation with the key's purpose). I don't normally make changes like this, since it does affects users who are used to things, but this situation warrants it. It's not likely used often in practice anyway, as you pointed out.
< I'm sure these would be very useful, if you can't make cells that always expand vertically to fit the text or make the cells expand automatically while the user type
I assume you're familiar with the "Optimize size of all cells" setting, "Ctrl + M". You won't notice its effect though unless your strings wrap more than one line. I have actually investigated this whole situation in a lot of detail though. It actually works quite well now IMHO, for the most part, but it's not always perfect. There are certain issues though that make getting it "perfect" very difficult, some due to MSFT technical limitations. I struggled mightily with them. The next release will nevertheless be even closer to that "perfect" ideal. Even now though, unknown to most perhaps (I should include it in the docs), if the "Optimize size of all cells" setting isn't on, you can drag the horizontal border on each row up or down to your liking (in the far left column only). If you'ld like to see the next release in action (or want to provide feedback), let me know and I'll send you an (early) beta version.
< CAT issues
Thanks for your valuable feedback on this (truly). I'll definitely be consdering all of it when I look into CAT. ▲ Collapse
| | |
|
|
|
Samuel Murray
Paesi Bassi
Local time: 03:32
Membro (2006)
Da Inglese a Afrikaans
+ ...
Jeff wrote:
Samuel wrote;
The form view editing can be improved by making "Cancel" the default option when the translator tries to exit the form view without saving. Otherwise the translator might lose work if he didn't realise that pressing "OK" means "Okay, lose my work"
Not sure I follow this one. "OK" always saves all changes. If you try to cancel however, using any means ("Cancel" button, "x" on the upper-right-hand corner, "Alt + F4"), and any changes were made, the program will warn the user.
Hmm, you're right... clicking the "X" really means "Cancel".
I tend to click the X when I want to close a window, but I never previously thought of clicking the "X" as meaning "Cancel". In many programs, if you click the "X" with unsaved changes, you are told that you have unsaved changes, and asked if you are sure, and possibly also asked what you want to do. The default option in most cases is either "don't exit" or "save and exit". I must confess that I often don't read the message -- I just assume that the default option is safe.
[Edited at 2012-09-27 12:09 GMT]
| | | | Lydie Parisot
Francia
Local time: 03:32
Da Francese a Inglese
+ ...
AVVIO ARGOMENTO | Transview, Transvoo and CSV | Oct 23, 2012 |
Samuel Murray wrote:
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]
Samuel,
Getting back to you on Transvoo, I was unable to try your app due to issues with CSV export from Transview. It could be that the files I was working with, contained software strings that were too long (some several paragraphs in length) or contained confusing markings. For whatever reason, I was unable to export a useful CSV file except in one case and after multiple transitions through openoffice, notepad, wordpad and csv file editor and back and forth.
In general the file was either unreadable due to extra "invisible markup squirrelies" from Transview at the beginning of the file (like MS Word enjoys), or else it unfolded in a cvs editor as one endless cell of text strings all together and / or endless extra columns of string bits of what should have been one single column. Transview lack capability of specifying field enclosures etc.
In the end, it was "faster" to do the hand translation in TV and then copy paste each string source and translation into a blank cvs file and create a TM after the fact..for next time. Still will have to work as a copy/paste but better than re-translating every time.
Transview, in my experience, does export to CSV but not in an immediately re-usable form, at least in the software strings documents case I had.
May you be granted texts that open in Poedit, OmegaT and Anaphraseus. (smile)
Lydie
| | | | Samuel Murray
Paesi Bassi
Local time: 03:32
Membro (2006)
Da Inglese a Afrikaans
+ ...
Lydie Parisot wrote:
Getting back to you on Transvoo, I was unable to try your app due to issues with CSV export from Transview.
I've written an updated version (which I could not test, unfortunately, because I don't have complex files to test it on), which includes an updated user manual that explains the CSV thing also. You're welcome to give it a go.
http://wikisend.com/download/141958/TranzVoo%20v2.zip
| | | | | Pagine: < [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 » |
| | Wordfast Pro | Translation Memory Software for Any Platform
Exclusive discount for ProZ.com users!
Save over 13% when purchasing Wordfast Pro through ProZ.com. Wordfast is the world's #1 provider of platform-independent Translation Memory software. Consistently ranked the most user-friendly and highest value
Buy now! » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
