Pages in topic:   [1 2 3] >
Studio 2009 - How to modify text in source segment
Thread poster: Pascale Pluton

Pascale Pluton  Identity Verified
Netherlands
Local time: 16:57
Member (2005)
English to French
+ ...
Sep 15, 2011

Dear all,

I recently started using Studio 2009 and I am not quite comfortable with all the possibilites it offers yet.

One I appreciated much in de previous version was the possibility to modify the source text.
Very handy when you need to correct an error in the source text or when a sentence in the source text is plit into severals segments which can not be merged (presumably because of a hard return in the source text), and when the segment order in the target language is different.

Would someone know how I can access the source text in Studio 2009?

I briefly looked in the manual but to be honnest I am running short of time to investigate further. So my appology if this question has been asked already.

Many thanks for your suggestions

Pascale


 

Tapsa
Local time: 17:57
English to Finnish
Two tedious workarounds Sep 15, 2011

There is no direct solution to this problem (which is a shame), but there are two workarounds.

1. If you have the original file, edit it and open it in Studio.
2. When you have translated the segment, go back to it (click it) and wait until the translation unit shows in the Translation results -pane. Now, right-click the TU in Translation results pane and select edit. Now you can edit both the source and the target. You can use this method also in Translation memories -pane (open your TM, search for the TU and edit it).

With a little bit of creativeness, you can "join" segments using method 2. Translate all segments in one of the split segments and confirm it. Then, use the method 2 to add missing source segments to TU (you can highlight them and use copy and paste). After doing this, you should clear the missing segments (if there are for example fuzzy matches or whatever) and mark them as translated.


 

Pascale Pluton  Identity Verified
Netherlands
Local time: 16:57
Member (2005)
English to French
+ ...
TOPIC STARTER
handy but time consuming Sep 15, 2011

Thank you very much for taking the time to answer me Tapsa

I can hardly believe that there is no direct solution...
Not that I call you a liaricon_wink.gif but it seems to me such a nonsense. If I believe SDL, this product should increase my rapidity, not my creativeness ... icon_wink.gif

Well, something I hope SDL will fix in a version very soon.

I unfortunatly do no own the In Design software required to open the source, so I decide to provide the translation 'off Studio' and to let the Translation agency to the pasting. At least, the burden is shared.... and the translation memory is not polluted by rubbish.

I'll keep solution number 2 in mind, it is a very handy one

Have a nice evening


 

jimshanks
Local time: 15:57
Dutch to English
Not going to happen Sep 15, 2011

As far as I am aware SDL do not believe translators should change source text and there is no way to do it. Nor do I believe that they are planning to introduce this in any of their software.
I have vague recollections of this being discussed elsewhere in this forum.

[Edited at 2011-09-15 21:19 GMT]


 

Dominique Pivard  Identity Verified
Local time: 17:57
Finnish to French
Some other tools can do it Sep 16, 2011

Pascale Pluton wrote:
I can hardly believe that there is no direct solution...

FWIW, some other tools can do it: in memoQ, for instance, all you have to do is put the cursor in the source segment and hit F2 (like in Excel), and you will be able to edit the source text (for instance, fix a typo).


 

SDL Community  Identity Verified
United Kingdom
Local time: 16:57
English
Not quite accurate... Sep 16, 2011

jimshanks wrote:
As far as I am aware SDL do not believe translators should change source text and there is no way to do it. Nor do I believe that they are planning to introduce this in any of their software.


Hi Jim,

It would be true that we have a lot of customers who would be very unhappy to see the source changed in a bilingual document that was returned to them. The reason for this is that all changes, in a controlled environment, go through a seperate change control process and the time taken to manage these changes is recorded and billed. If the translator is allowed to make the changes themselves then there is a potential for wasted non-recoverable time, lack of change control and unwanted changes.

It would also be true to say that there is a definite requirement to allow this under different scenarios of course and there are plenty of good reasons as we have seen recorded here many times.

So the solution, for our userbase, may be to allow this but also provide controls to prevent it within a Project if desired (pending GG posting a workaround on how to avoid thisicon_wink.gif). This will happen in a future release; and not too far into the future. So I am hopeful we will see this next year.

Regards

Paul


 

ahmadwadan.com  Identity Verified
Kuwait
Local time: 17:57
English to Arabic
+ ...
It should be existed Dec 29, 2011

Such feature is important. I need it daily.

Please SDL, make it handy! At least, you can lock/unclock source.

Thank you


 

Giovanni Guarnieri MITI, MIL  Identity Verified
United Kingdom
Local time: 15:57
Member (2004)
English to Italian
GG... Dec 29, 2011

SDL Support wrote:

So the solution, for our userbase, may be to allow this but also provide controls to prevent it within a Project if desired (pending GG posting a workaround on how to avoid thisicon_wink.gif). This will happen in a future release; and not too far into the future. So I am hopeful we will see this next year.

Regards

Paul


I'm not that GG icon_smile.gif but I really hope you will implement this in the not distant future... would be really useful...

GG icon_biggrin.gif


 

John Fossey  Identity Verified
Canada
Local time: 10:57
Member (2008)
French to English
Not up to SDL to decide Dec 29, 2011

SDL Support wrote:
...
If the translator is allowed to make the changes themselves then there is a potential for wasted non-recoverable time, lack of change control and unwanted changes.
...
Paul


Since when is it up to SDL to decide what the translator is or is not allowed to do?

This is indeed an important feature in a CAT tool. Lack of this feature is one of the reasons why I frequently choose other tools to do a job with, rather than Studio, although I have Studio 2011. Source texts are frequently full of typos and such errors which mean that the TM or concordance search doesn't find matches. There may be other reasons why the source text needs to be corrected.

[Edited at 2011-12-29 15:18 GMT]


 
Post removed: This post was hidden by a moderator or staff member because it was not in line with site rule

SDL Community  Identity Verified
United Kingdom
Local time: 16:57
English
You missed a point... Dec 29, 2011

Hi John,

I went on to say that ...the solution, for our userbase, may be to allow this but also provide controls to prevent it within a Project if desired. This will happen in a future release; and not too far into the future. So I am hopeful we will see this next year.

Our business is built around many customers and despite the personal viewpoints of some of the users in here I can assure you that allowing this without controls is not something the majority of our customers want or need. If it was then I can also assure you that we would have done it by now.

So it is not up to us at all. We are guided by the needs of all our users and allowing this with a simple F2 or similar is not something that would be found acceptable at all for the majority.

Regards

Paul


 

Jerzy Czopik  Identity Verified
Germany
Local time: 16:57
Member (2003)
Polish to German
+ ...
I beg to disagree here Dec 29, 2011

SDL Support wrote:
...
So it is not up to us at all. We are guided by the needs of all our users and allowing this with a simple F2 or similar is not something that would be found acceptable at all for the majority.
...


Indeed I do not know much about the majority or minority and I also must admit, that I do not care that much.
What I see is, that many "end user" of the CAT software solutions, namely all those at the end of the food chain (you can call them also freelance translators, who do not seem to be in the main line of interest of most customers or tool providers) would like to have this feature.
Maybe we have a bit of misunderstanding here.
While I fully accept and understand, that no customer wishes to have his text edited externally by a translator, a translator however may have a very distinctive and reasonable need to influence the source by at least being able to merge the segments over paragraph boundaries.
This is much more important in my opinion than the ability to change a typo in the text provided by the customer - in fact this can be indeed contra productive in many situations. But the real problem in my opinion is, that many (really many, if not most) customers (at least most customers of mine) seem not to understand the need of keeping the TM clean and not allowing any cross translations and broken segments there. These are poison, at least in my case, when translating from GE into PL, but I can imagine this being a big problem also for any other language pair.
So instead of defending the customers right to have his text unedited by a translator I would just opt for allowing us to have the possibility to join segments as necessary.
And for the argument of content management systems, which would need to keep the segmentation untouched: sometimes the smalest part of the process, located at the end of the food chain, my be right in terms of the necessity of changing the segmentation. This is because really many customers cannot imagine the results of such segmentations and the impact on the meaning in the target language. While in English it will be possible to change the meaning of anything by adding a simple negation (press the button vs. do not press the button, where "press the button" and "do not" will be stored as separate segments), this will for example not work for at least Polish. Same applies to many German texts, mainly software modules for machines and so on.
So a dialog here would be what is needed, but in case when such dialog is not in place the translator should be able to decide, not the customer. Once again, the customer will not be aware of the real impact in the target language, so I am for forcing him to listen.


 

SDL Community  Identity Verified
United Kingdom
Local time: 16:57
English
Disagree with what? Dec 29, 2011

Hi Jerzy,

I don't see a disagreement here. Actually I personally agree with you on the merging over paragraph boundaries, and also would have liked to see edit source sooner.

But none of this changes what I said. I only said that we are guided by our users and that means doing things in the priority set by the strategic needs of our business. So from this perspective it is entirely up to SDL what is provided and hopefully for the majority of the users we provide the right things, and in time will hopefully be "all things to all men". Making these decisions on what we do and when we do it is never easy, but we have to take responsibility for the result... not the end users and there is a lot more going on than we see here in ProZ.

Notwithstanding this the opinion of Freelance Translators is important and I think we have done a lot to try and improve the software for this group. In fact each group of users will tell us from time to time that we don't listen to them, only to everyone elseicon_wink.gif

Regards

Paul


 

hhl
Local time: 16:57
English to German
Difficult for .itd format Dec 30, 2011

An interesting discussion. I fully support Jerzy's input.
However, for my situation (and the situation of dozens or hundreds of my collegues from German and other worldwide languages, all translating content for the same end customer), things are probably a bit more complicated, as we do not receive the original document formats for translation, but a bilingual pre-translated format ... and it is a shame in the year 2011, which format that is!!! Guess what ... it's .ITD. The .itd jobs make up for more than 95% of all my work. And what we get is far from correctly prepared files. Much of the translation volume is delivered through SDL's "TMS" system, and the filters there care for (example) making "...this is U.S. specific text..." TWO segments(!), because the fullstop after "U.S" is identified as segment end ... and many more of such errors (should I mention hard breaks within 2-line 3-word headers etc? - no, not again).
CAT systems should obviously make the translator's life easier - but for me there were introduced more and more roadblocks for my work during the last decade (driving down my revenue), virtually all due to the quality (content+preparation) of the source file/format.
Now, with Studio 2009/2011, we have a really nice tool, but big problems with applying it. With SDLX (who uses that last-century tool?) you can still "merge" (or join) segments like the "U.S." example above, but if you load such bi-lingual format into Studio, you can no longer merge ANY segments! You can split them, but never merge. Currently we (collegues an me) are really frustrated with this situation.
It does not help to state that .itd is an outdated format, and we should look into the future, as I cannot see that I could get rid of this intelligence- and creativity-killing translation process for the years to come.
I have even looked at editing the source of the xxxx.itd.sdlxliff files (in an editor like notepad++), and make the option to edit the source part of translation units an App for the Exchange Initiative of SDL, but that does not work. Actually, you can edit the source text in the .sdlxliff file as you want (and you see the new text in the Studio editor), but when you write back the .itd file format, Studio will use the original (coded) content for the "final" .itd file. The changes you made in the source parts of the .sdlxliff files are simply ignored.

So, at least for the .itd format, I cannot see the introduction of a feature allowing source side edits. From what I said above, this would mean a completely new processing of the input format, not just adding a feature. - And the opinion, that "SDLX format" (i.e. .itd) is no longer an "important" and "current" format, which needs extensive support within Studio, is obviously only in the heads of a part of the SDL people, while others (the TMS side) still stick to the old times of non-Trados SDL tools (ok, you can also have TagEditor files downloaded from TMS - but no .sdlxliff!). - Not to be misunderstood: I myself (and my collegues) dislike (or should I say "hate"?) the unflexible .itd file format since years, and for the years to come. So I'd like to urge contacts like you, Paul, to insist on a change in TMS translation workflow. Help us!icon_smile.gif


 

Jerzy Czopik  Identity Verified
Germany
Local time: 16:57
Member (2003)
Polish to German
+ ...
@Paul Dec 30, 2011

What I disagree with is this statement (bold from me):
So it is not up to us at all. We are guided by the needs of all our users and allowing this with a simple F2 or similar is not something that would be found acceptable at all for the majority.

This means to me, that customers are given the right to treat us translators as small children.
TBH I quite often had this situation in the past (my luck is I could sort many of those customers out or convince them I am mature enough to be given the original source), that due to the general attitude against translators we never were able to get editable source, but always so called "prepared text". Very often I was told, that "our DTP will sort that out". So instead of getting an InDesign file I've got some obscure badly segmented RTF file and the information "our DTP will sort that". In the end we have got the PDF for correction, where I had to change 90% of things only due to bad hyphenation or formatting, as the "DTP of the customer has sorted that" accordingly to their knowledge of the target language, tending against zero... With TagEditor I was at least able to cut and paste sentences together, leaving empty segments (or inserting something there which could be easily removed after the target file has been produced). Now in Studio I can't.
So if I get a file from the customer, where I have
Hexagon<br>
screw

I need to translate it into Polish like this
Śruba z łbem<br>
sześciokątnym

where you get the word screw for hexagon and hexagon for screw.
Then you have:
Hexagon<br>
nut

and your TM (a PM will of course use the cleanup and pretranslation) will deliver:
Hexagon<br>
Śruba z łbem<br>
with your additional translation
nakrętka


This reads in English:
Screw with head<br>
nut


This is a really perfect translation - but nearly 80% of all customers do not see the problem!


 
Pages in topic:   [1 2 3] >


To report site rules violations or get help, contact a site moderator:


You can also contact site staff by submitting a support request »

Studio 2009 - How to modify text in source segment

Advanced search







WordFinder Unlimited
For clarity and excellence

WordFinder is the leading dictionary service that gives you the words you want anywhere, anytime. Access 260+ dictionaries from the world's leading dictionary publishers in virtually any device. Find the right word anywhere, anytime - online or offline.

More info »
SDL MultiTerm 2017
Guarantee a unified, consistent and high-quality translation with terminology software by the industry leaders.

SDL MultiTerm 2017 allows translators to create one central location to store and manage multilingual terminology, and with SDL MultiTerm Extract 2017 you can automatically create term lists from your existing documentation to save time.

More info »



Forums
  • All of ProZ.com
  • Term search
  • Jobs
  • Forums
  • Multiple search