| Pages in topic: < [1 2 3 4] | Déjà Vu X3 is here! Thread poster: Etienne Tessier
|
|---|
| I experienced same bug! | Aug 24, 2014 |
I have experienced same bug in English-Korean pair. This might be related to Asian languages.
Enlandtrans wrote:
Dear Etienne,
As a user passing through DVX, DVX2 to the lastest DVX3, I have to indicate a boring and long-standing bug: in the segment interface, when lines of the target segment is larger than those of the source one and you go to the next segment by typing Ctrl+Down arrow key, the aforesaid target segment is marked with the Finished Mark, but with the last half part of it invisible - that's to say, the target segment is displayed only in the same lines as the source segment!
I've ever informed DVX development team of it, but no work seems be done as it still occurs even in DVX3.
Some work has to be done to solve it.
| | | |
I reported the same problem approximately two years ago when I was still working with DVX 2, but I was told that since they couldn't reproduce it nothing could be done. I even sent Atril some screenshots to show how DV was ( and still is) even automatically changing font in the translation grid. More precisely, while typing everything would be all right, i.e. DV uses the font specified in the Display setting, but after advancing to the next cell I can see the previous segment switching to a diff... See more I reported the same problem approximately two years ago when I was still working with DVX 2, but I was told that since they couldn't reproduce it nothing could be done. I even sent Atril some screenshots to show how DV was ( and still is) even automatically changing font in the translation grid. More precisely, while typing everything would be all right, i.e. DV uses the font specified in the Display setting, but after advancing to the next cell I can see the previous segment switching to a different font, usually up to the first accented letter encountered in the target text, which it shows with the typical double-byte representation of single byte characters). The most serious problem, however, is that when I want to go back and change something in the previous target cell often I cannot even see the whole text.
Actually, I call this a problem, not a bug, because I suspect that it might be caused by the type of OS installed and its interactions with DV through Microsoft IME. For example, mine is the native Windows 7 Japanese. Is yours perhaps the Korean native version? This problem here started to appear all of a sudden, maybe (but I am not sure) as a result of one of the many Windows 7 updates. I should also say that it has been occurring since then on all our Win 7's Japanese version OSs, and I don't know if Atril has a test machine with Microsoft IME installed to check their builds with double-byte fonts.
The only way to reduce the extent of the problem (although not eliminate it entirely) is trying with various fonts (size included) for both source and target cells. The best results I have obtained so far is with Veronica Sans 11 for both source and target cells.
This is the most serious problem I have been encountering with DVX 2/3 so far, which led me to trying other CAT tools. However I have been unable to switch, since no other CAT software has the DV-like Lexicon feature.
Mario Cerutti
www.aliseo.com/english/ ▲ Collapse
| | | | | Same with me | Sep 14, 2014 |
Mario Cerutti wrote: I reported the same problem approximately two years ago when I was still working with DVX 2, but I was told that since they couldn't reproduce it nothing could be done. I even sent Atril some screenshots to show how DV was ( and still is) even automatically changing font in the translation grid. More precisely, while typing everything would be all right, i.e. DV uses the font specified in the Display setting, but after advancing to the next cell I can see the previous segment switching to a different font, usually up to the first accented letter encountered in the target text, which it shows with the typical double-byte representation of single byte characters). The most serious problem, however, is that when I want to go back and change something in the previous target cell often I cannot even see the whole text. Actually, I call this a problem, not a bug, because I suspect that it might be caused by the type of OS installed and its interactions with DV through Microsoft IME. For example, mine is the native Windows 7 Japanese. Is yours perhaps the Korean native version? This problem here started to appear all of a sudden, maybe (but I am not sure) as a result of one of the many Windows 7 updates. I should also say that it has been occurring since then on all our Win 7's Japanese version OSs, and I don't know if Atril has a test machine with Microsoft IME installed to check their builds with double-byte fonts. The only way to reduce the extent of the problem (although not eliminate it entirely) is trying with various fonts (size included) for both source and target cells. The best results I have obtained so far is with Veronica Sans 11 for both source and target cells. This is the most serious problem I have been encountering with DVX 2/3 so far, which led me to trying other CAT tools. However I have been unable to switch, since no other CAT software has the DV-like Lexicon feature. Mario Cerutti www.aliseo.com/english/
I encountered the same circumstance you said above. I have to select my font from a limited number of fonts in the setting window so as to have it displayed normally in the grids, such as Arial.
| | | | hy-trans
Local time: 09:22
Russian to Armenian
| armenian fonts | Dec 17, 2014 |
when typing armenian letters there are diplayed the qustion marks.
changing fonts through file->options->display->fonts did not help.
[Редактировалось 2014-12-17 11:50 GMT]
| | |
|
|
|
| Input method | Dec 17, 2014 |
hy-trans wrote:
when typing armenian letters there are diplayed the qustion marks.
changing fonts through file->options->display->fonts did not help.
[Редактировалось 2014-12-17 11:50 GMT]
Hello,
Which input method are you using for armenian?
Also, please note that we are currently working on solving the issues with Korean and Japanese languages.
Regards,
ATRIL Team
| | | |
Atril Team wrote:
Also, please note that we are currently working on solving the issues with Korean and Japanese languages.
Regards,
ATRIL Team
Atril seems to be working on solving the issues with the Japanese language since when DVX2 came out several years ago. Let's hope this is *the* right time.
| | | | hy-trans
Local time: 09:22
Russian to Armenian
Atril Team wrote: hy-trans wrote:
when typing armenian letters there are diplayed the qustion marks.
changing fonts through file->options->display->fonts did not help.
[Редактировалось 2014-12-17 11:50 GMT] Hello, Which input method are you using for armenian? Also, please note that we are currently working on solving the issues with Korean and Japanese languages. Regards, ATRIL Team
directly from keyboard or through the spec. program KDWin.
keyboard layouts - ru, en, hy
[Редактировалось 2014-12-18 06:13 GMT]
| | | |
Mario Cerutti wrote: Atril Team wrote:
Also, please note that we are currently working on solving the issues with Korean and Japanese languages.
Regards,
ATRIL Team Atril seems to be working on solving the issues with the Japanese language since when DVX2 came out several years ago. Let's hope this is *the* right time.
A new beta build is available which fixes all the issues with Korean/Japanese languages. It is not public yet but let me know if you want to test it. I could provide you with a link to install it.
@Hy-Trans: Would you please provide [email protected] with example, screenshots and such? We would like to investigate this further
Kind regards,
Atril Team
| | |
|
|
|
hy-trans
Local time: 09:22
Russian to Armenian
Atril Team wrote: Mario Cerutti wrote: Atril Team wrote:
Also, please note that we are currently working on solving the issues with Korean and Japanese languages.
Regards,
ATRIL Team Atril seems to be working on solving the issues with the Japanese language since when DVX2 came out several years ago. Let's hope this is *the* right time. A new beta build is available which fixes all the issues with Korean/Japanese languages. It is not public yet but let me know if you want to test it. I could provide you with a link to install it. @Hy-Trans: Would you please provide [email protected] with example, screenshots and such? We would like to investigate this further Kind regards, Atril Team
it can be seen here http://youtu.be/KgexC30xpM8
4moderator - now it is in public access
| | | | | Thank you... | Jan 22, 2015 |
... for the video. We will investigae it.
@Everybody: Build 723 is now public - it contains all the fixes for Korean/Japanese languages.
Kind regards,
Atril Team
| | | | | Not all "bugs" fixed | Jan 24, 2015 |
I have been using the latest build since a couple of weeks now and I am rather positive that not all Japanese language-related bugs have been fixed.
For instance, DVX3 still doesn't automatically insert a period at each translated sentence end (Italian in my case). This can only be done manually in the exported file, which is obviously not good for productivity. I have raised this issue several times in the past. I am no programmer, but I believe it should be rather easy to tweak D... See more I have been using the latest build since a couple of weeks now and I am rather positive that not all Japanese language-related bugs have been fixed.
For instance, DVX3 still doesn't automatically insert a period at each translated sentence end (Italian in my case). This can only be done manually in the exported file, which is obviously not good for productivity. I have raised this issue several times in the past. I am no programmer, but I believe it should be rather easy to tweak DVX3 to this on its own.
Second, in many cases (but not always) DVX3 surrounds double-byte numbers with codes. It shouldn't be like this since there is no encoding transition from the surrounding double-byte text and numbers themselves.
Although I can't strictly call these "bugs", in the sense that the program's main components allow to work anyway with Japanese, in my opinion it speaks volumes about the pace DV is being developed and maintained, particularly in regard to non-mainstream languages.
Finally, but not related to Japanese only, it should be about time to fix the integrated error reporting system. Whenever DVX3 crashes and offers to send an error report via the internal reporting system, after accurately typing the requested error description and pressing "Send" a message appears saying "The report could not be sent" or something similar. This is happening consistently to me since at least a couple of years and I have stopped using this function altogether. ▲ Collapse
| | | | Michael Beijer 
United Kingdom
Local time: 07:22
Member (2009)
Dutch to English
+ ...
|
|
|
| Various comments | Jan 26, 2015 |
Mario Cerutti wrote:
I have been using the latest build since a couple of weeks now and I am rather positive that not all Japanese language-related bugs have been fixed.
All the issues reported above have been fixed. If you encounter another one, please contact us or detail it here - that would be of great help.
For instance, DVX3 still doesn't automatically insert a period at each translated sentence end (Italian in my case). This can only be done manually in the exported file, which is obviously not good for productivity. I have raised this issue several times in the past. I am no programmer, but I believe it should be rather easy to tweak DVX3 to this on its own.
This is actually normal and intended behavior: we don't want DVX3 to automatically insert a period in any target segment. That would be too cumbersome especially for segments that must not contain a final period, and also because punctuation can be adapted/chosen by the translator.
On another hand, you can enable the "Adapt leading/trailing punctuation" option under "File>Options>Translation>Automatic conversion options". Doing so, DVX3 will automatically insert a final period when:
- It is to be found in the source
- The match/portions inserted in the target does not have period
That works with any other trailing punctuation mark (column, semi-column etc.) and is a preferable alternative as it can be adapted to the translator’s own style and workflow. Is that what you were looking for?
Second, in many cases (but not always) DVX3 surrounds double-byte numbers with codes. It shouldn't be like this since there is no encoding transition from the surrounding double-byte text and numbers themselves.
Please send us some examples demonstrating this. That should not happen except when such numbers contain specific formatting information. In what kind of files did you see this? Which filters were you using?
I know this was quite a challenge to solve, especially in the new "Live" filter. But our japanese beta testers were positive: it disappeared in build 723. Again, providing us with examples would be of great help in order for us to investigate it.
Although I can't strictly call these "bugs", in the sense that the program's main components allow to work anyway with Japanese, in my opinion it speaks volumes about the pace DV is being developed and maintained, particularly in regard to non-mainstream languages.
The list of fixes/developments/feature implementations are listed here. The vast majority of our clients working with Japanese and Korean did not experience this. We were able to fix the issues with those languages once we could reproduce them. In that perspective, your input – amongst other things – was of great help. We count among our clients, translators and companies from all over the world and support virtually any language within the software. Any reported issue is carefully analyzed in view of optimizing your work with Déjà Vu.
Finally, but not related to Japanese only, it should be about time to fix the integrated error reporting system. Whenever DVX3 crashes and offers to send an error report via the internal reporting system, after accurately typing the requested error description and pressing "Send" a message appears saying "The report could not be sent" or something similar. This is happening consistently to me since at least a couple of years and I have stopped using this function altogether.
The integrated error reporting system works well in my experience (and based on other users experience as well) - I have just tested it. Can you check that no firewall or other settings is blocking the communication? Does that happen to anyone else? If you can't submit the errors, feel free sending them to [email protected]
Kind regards,
Atril Team
| | | | | Reply to Various Comments | Jan 29, 2015 |
Atril Team wrote:
All the issues reported above have been fixed. If you encounter another one, please contact us or detail it here - that would be of great help.
I have just sent Atril a small test project with three pairs of source and target files to show that not all bugs have been fixed.
Atril Team wrote:
We don't want DVX3 to automatically insert a period in any target segment. That would be too cumbersome especially for segments that must not contain a final period, and also because punctuation can be adapted/chosen by the translator.
Sorry, my fault. I didn't mean "automatically inserting a *period* in any segments", but rather "automatically inserting a *space* after end-of-sentence periods. In the target files mentioned above it's clear that spaces are not added automatically, nor DVX3 asks whether I want to, but of course they are necessary (in Italian) while they are absent (they are not used) in Japanese. These files also show that in certain situations double-byte numbers do not automatically convert to single-byte numbers even after re-typing them manually as single-byte numbers in the translation grid.
Atril Team wrote:
The integrated error reporting system works well in my experience (and based on other users experience as well) - I have just tested it. Can you check that no firewall or other settings is blocking the communication?
Just yesterday I had another chance to prove that, at least in my case, the DVX3 error reporting system doesn't work. My Windows firewall is set to allow Déjà Vu's external communications, but I couldn't send my error report message: "The error report could not be sent".
I hope this small contribution help Atril further fine-tune DVX3 when dealing with Japanese as a source. For the rest I am a happy user, although I have been suffering a rather fastidious visual glitch that Atril "couldn't reproduce".
Thank you and kind regards,
Mario Cerutti
| | | | | These are not bugs | Jan 29, 2015 |
Thank you for the files Mario,
Please find below my comments:
Scenario 1 - File is imported with previous versions of MS Word filters:
"1. No spaces are automatically added after periods in the Italian translation and DVX3 didn’t ask whether I wished to add them."
DVX will offer you to add an extra-space in the target when:
- it is to be found in the source (not here, obviously)
- it is missing in the target
In... See more Thank you for the files Mario,
Please find below my comments:
Scenario 1 - File is imported with previous versions of MS Word filters:
"1. No spaces are automatically added after periods in the Italian translation and DVX3 didn’t ask whether I wished to add them."
DVX will offer you to add an extra-space in the target when:
- it is to be found in the source (not here, obviously)
- it is missing in the target
In this very case (Japanese source with no space at the end of each segments), DVX will not offer to add an extra-space in the target for the reason mentioned above. My advice would be for you to use the Search and Replace feature : Look for "Period" in the target and replace it with "Period/Space". Then, replace the double spaces with single spaces, just to make sure. If you do that at the end of the translation process, it takes literally five seconds.
"2.Item numbers kept their double-byte format even if in the source cell I replaced them with single-byte numbers."
In the source file, the numeral list has a different font. Hence the tags, which are there to keep this formatting/font. That is why I would advise you to use the new "Office (Live)" filter, which brings me to the next point
Scenario 2 - File is imported with MS Office (Live) filter:
"1.No spaces are automatically added after periods in the Italian translation and DVX3 didn’t ask whether I wished to add them."
See above. The same applies.
"2.Item numbers kept their double-byte format. I couldn’t replace them with single-byte numbers because they didn’t show up in the translation grid (correctly, I think)."
The new filter does not show the numeral list since it is external to the text.
On another note, the same will apply in the exported file - the source layout is preserved because this is what we want. Then, that is for you to change the font of such list if you wish to do so.
Another comment: the source text contains numbers - you can see that they are not surrounded with tags (because they are part of the text and have the same font) and that they are exported normally in the target file. They did not keep their "double-byte" format.
Kind regards,
Atril Team ▲ Collapse
| | | | | Pages in topic: < [1 2 3 4] | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Déjà Vu X3 is here! | Protemos translation business management system | Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!
The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.
More info » |
| | CafeTran Espresso | You've never met a CAT tool this clever!
Translate faster & easier, using a sophisticated CAT tool built by a translator / developer.
Accept jobs from clients who use Trados, MemoQ, Wordfast & major CAT tools.
Download and start using CafeTran Espresso -- for free
Buy now! » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
