[These pages concern interesting correspondence between our translators and project managers at KENAX, mostly concerning the famous Jade Dynasty translation project.]

Replace German Grammar Glossary Terms

Personally I want it fast because I have no idea how long this will take, so a day saved could mean the difference between meeting the deadline and being late.

If you want to contact Karel and wait, go ahead, provided that you feel this will save time in the long run. On the other hand I would suggest having alternatives. E.g., tell us what info you need in case we can answer. Or excise the parts that need clarification and do that later.

File format is Excel. I do, and I believe Valeria does.

Yes, I prefer having grammar be considered and accounted.

I don’t know what the proofreading strategy after term insertion yet. Any suggestion?

The insertion itself will be done using a VBS script. It will look for terms and replace it with another term. The main idea is to replace all the old glossary terms with the latest updated terms.

NOTE: Some terms can’t be handled by a script. When two English terms have the same German translation and we want to change that so it will have two different translation, the search and replace will have to be handled manually.
Currently I have only one known example. Grave Raider and Grave Robber were both translated as Grabrauber but later on Grave Raider got a separate translation as Grab Plunderer.

———————-

, there will probably be quite a few of these cases, because the customer admonished quite a few of them. I guess the VBS script does not look into the source?

About proofing: I guess proofreaders will not run the VBS themselves, will they? So they may have no idea what has been inserted in particular file and will have to check through the whole thing? I think it would be great to be able to mark the insertions somehow. I just had the idea that we could possibly insert the terms like this:
Old term: Magieschaden
New Term: Magie-Schaden
Term we could insert: Replace Magieschaden with: M$$agie-Schaden or something.
That way, the proofer would only need to search for $$ and would find all the insertions. They can then also take care of grammar, which is hard to do centrally with the glossary, because there may be so many different occurences/forms.

About the two terms in the source getting translated as one:

If a list of these were created, we could still replace all of them and the proofers could then look into the source and adjust accordingly.

Trying to think up something.

———————-

Sorry for not replying immediately. Was working on a different aspect of the project.

I would like to know what the customer admonishments are. It will give some idea on how to improve things for BOI. The VBS script itself is quite simple, of the “Find X, replace with Y”. A VBS script or Excel macro does not have the sophistication to look at the source text. So it won’t be able to check the English text and considers “If English term is A, then use translation Z instead of Y.”

Proofreaders won’t be running the script either. Can’t expect them to and there’s no point. It’s not like they’ll be able to see the script changing things nor make corrections during runtime.

Your idea with the $$ is pretty good. Alternatively Word’s Compare Documents feature might be useful too. Which one are you most comfortable with?

One big consideration for this project is budget. If we have unlimited budget I’ll simply have the whole thing re-proofread thoroughly. But we don’t. So we’ll have to be smart with the automation instead. We have 314 files, and we can afford at most 15 minutes of second round proofing per file. If we take out the time we’ll be spending on the automation process itself (i.e., your own time making the S&R list), we have, eh, maybe 12 minutes per file.

Anyway, tell me what the customer has been saying about JD German. I can then figure out a plan to avoid repeating the same mistakes then.

———————-

Unfortunately, the customer’s comments are mostly a heap of unusable rubbish and usually arrive too late to really make substantial changes. It’s been a week since I responded to their criticism and they haven’t responded yet.

So what’s most important to them is the issue of having the same German term for more than one English term. This is utterly hard to avoid, since German is a complicated, but not as wordy a language as English. I have changed the most severe issues of this in my latest glossary update. Karel told me to make executive decisions on terminology because the client is not responding and I did.

The Compare Documents feature is also useful, I think. I’m wondering if it takes more time to have to switch between Excel and Word constantly while reproofing in Excel, though, than to be able to stay in Excel and to later get rid of something like the $$. Maybe we can use the $$ method and use the compare documents for very fast checking.

What’s more, client feedback on JD German has been sparse and incoherent, to say the least. I can’t give you any useful instructions on that, I’m afraid.
What I’m wondering is if I give you a list very soon (like today) and we run into things needing to be changed, will it be possible? Or do I have to take full responsibility for the correctness of all the 10000 entries?

———————-

here is my first version. I haven’t received any word from the client, so it might as well be the final version. IF the client should still answer within the remaining two weeks, it might be possible to adjust this.
Regarding grammar adjustments:
I’m feeling a bit strained at the moment, and since this may well be a task requiring extreme concentration I’d rather not do this now. If you insist, I could get this to you by Tuesday night, I hope. I’m still not sure if it wouldn’t be faster to let spotcheckers mind the grammar adjustments, though.

has told Fabian (who could do proofreading and is high quality) that no proofers are needed anymore. Is this final?

———————-

Gerald.

Please, resolve the + mark in the attached file.

———————-

– I’m familiar with the customer’s comments being unusable. 🙂
– It should be possible to change things later for many things. We know which ones that are hard to change, e.g., capitalization, and so far we are okay with that.
– Speaking of ca

———————-

Hey

If you need my help with (light) proofreading, just let me know.

———————-

been reading the last few comments on this ticket and adding mine below. Perhaps you could start a new ticket as this one is getting long and it takes a while to load.

-delimiters in numbers (1.5 becomes 1,5 and 1,000 becomes 1.000)
-Finding and erasing double spaces within sentences or spaces in front of punctuation

> I can create a macro for this

———————-

there

so i figure this project is over. Do you have any idea when the next one starts or is there anything else to do?

Marcus

———————-

As for next project, no idea. We are hoping that we can use this project as a stepping stone into more projects, but this depends on the bigwigs in China liking:
1. Our result.
2. The MMORPG market projection in Europe.

As for something else to do, we’re in what we call the polishing stage. Right now we go over everything and make sure that the early files use the same terms and style as the later glossary, spellcheck (way too many people doesn’t spellcheck, and I seem to recall finding some typos in your files too, Marcus), fix misunderstood terms due to crazy English that they give us, and so on so on.

Unfortunately we don’t know yet if we need you for that part. Unlike the translation part, we want only a small team for this. Bigger teams leads to style issues. Because of that, we probably will not be using you for this stage. Of course, both  and Valeria will have their say on this, but the small team part is pretty much agreed upon.

I am sorry I can’t be more specific than this, but this is all the information I actually have at the moment.

———————-

This is not criticism and I want you to continue with the S&R list. I do want to ask you if you have any idea what to do about the following problem.

Looking at the S_R_Newform has the following entries:
Relikt R$$eliquie
Relikt-Aktivierungs-Grad R$$eliquien-Aktivierungs-Grad
Relikt-Handlungsanweisung R$$eliquien-Handlungsanweisung
Relikt III R$$eliquie III

There are other of similar forms.

In the first case what’s going to happen is Relikt will be processed first. This means Relikt-Aktivierungs-Grad will turn into R$$eliquie-Aktivierungs-Grad and that will stump the script.

Need to run more tests. This might be solvable simply by moving all the one word entries to the bottom, but that doesn’t work we may need to do it manually. The reason I’m posting is because I’m hoping you know a way to avoid manual search and replace (if moving entries around don’t solve this). If you do, let me know.

Regardless of the answer, keep doing the s&r list. Thanks.

” so how is the s&r list going? I was hoping to get that done within a day or two from start/by now so that the proofreaders could begin. Time is ticking.

“Karel

what I did was: I filtered down the glossary versions to those terms that had terminology changed. I then created the list in the format you asked for by assigning the term from the latest glossary to each changed term. So the list should be complete with regard to the glossary. Since the customer hasn’t answered yet, I’m unsure of a few things, e.g. avoiding some hyphenation. asked me to include grammar/conjugation/declination and I said that would be difficult. I can try to do that, but I’m not sure if this can’t be fixed more quickly by spotcheckers looking at the files.
Keeping you posted

———————-

would you like me to attempt and anticipate some of the different forms that the terms in my list may take within the text? That might also be a way to still be able to use the $$, as I would try to cover cases like Relikt- getting changed to Reliquien- instead of Reliquie-. However, I still haven’t been able to figure out a way to completely avoid such things. Maybe we could run the script on the list itself, starting with the one word entries and then add the cases where it didn’t work to the list again. Not pretty, I guess.

” Okay sounds good and keep up the good work. When will the s&r list be done? Need to move to the next stage.

here is some feedback from the customer:

I just got more feedback from Derick regarding this question. It came from
another German localizer that Derick has who also agrees that Level can be
used.

“I agree with Ingo. “Level” is a common expression among gamers.
Abbreviation: I’d prefer to capitalize LV (just as in JD) as well as all
other abbr. (exception: PvP). No mixing of “Stufe” and “LV” v.v. !”

——————————

Here is Derick’s team feedback to your question below:

“I think Level is fine for German, and it should go with the Lv
abbreviation for consistency. We just should avoid mixing stufe and level
and their abbreviations.”

[The first comment came last]

———————-

I haven’t received a definite answer on whether I should try and anticipate grammar. Since you previously said to do it, I went ahead and started. I’m also integrating a comment by the client. Have you started yet on running the script? Any experiences?
I think I should definitely invest the time to check the list again thoroughly, because I’ve come across a few examples where the S&R must be adjusted. Also, I think we should find a way to make absolutely sure we can find and proofread the pieces of text that were replaced. Maybe your Word-compare documents is the right thing for that and possibly better than the $$.

by

Leave a Reply

Your email address will not be published. Required fields are marked *