Localization of a .NET application Thread poster: Cagou
|
|---|
Cagou
Australia
Local time: 08:41
English to French
+ ...
Hi,
I am trying to localize a software developed in .NET. The software was developed using Virtual Studio and I am trying to localize it with SDL Passolo's .NET add-in... and having trouble...
My source file is an "xxx.exe" file and my target file is typically a "xxx.resources.dll" file.
Extracting the translatable resources from the "xxx.exe" file went fine and so did the translation part.
My target "xxx.resources.dll" file is also generated correctl... See more Hi,
I am trying to localize a software developed in .NET. The software was developed using Virtual Studio and I am trying to localize it with SDL Passolo's .NET add-in... and having trouble...
My source file is an "xxx.exe" file and my target file is typically a "xxx.resources.dll" file.
Extracting the translatable resources from the "xxx.exe" file went fine and so did the translation part.
My target "xxx.resources.dll" file is also generated correctly as far as I can see... (at least it ends up as planned in the correct "culture-locale" subfolder...)
BUT...
when I start the software itself and try to change the UI language to French (which is the language I'm translating to), the software does not identify my target dll and falls back onto the orginal language (English).
I have asked Passolo and they said may be the main assemblies were signed so I'd have to sign the satellite assemblies too (i.e. the target dll) but I asked the developers and they said their assemblies weren't signed...
So now I really don't know what to do...
Does anyone have experience in localizing .NET projects? Is there any software other than Passolo that I can use to do this? I like Passolo but if it does not do the job...
On the other hand the developers seem to think I should localize the ".resx" files individually and then recompile them with a utility or a script... but I cannot see that as a very workable solution (I'm a translator, not a developer...).
I've looked around on Microsoft's .NET webpages and they also seem to suggest using VS or "winres" to do this... but then you end up with no translation memory, no update managment, no translation QA tools, no statistics...how can this be an option?
Surely there must be some better way to do this...
So if anybody has suggestions to help me, it'd be great!
cagou ▲ Collapse
| | | | | Do not localize the exe file | Aug 19, 2010 |
The developers are right. You should not localize the exe file. I know that some localization tools claim to support this, but that is often not the case as this relies entirely on the way the software is developed.
You should definitely localize the resource files instead. The developers actually spend quite some time making the software localizable through resource files. And why not let the developers themselves recompile the software? That's not your job, and unless your word ra... See more The developers are right. You should not localize the exe file. I know that some localization tools claim to support this, but that is often not the case as this relies entirely on the way the software is developed.
You should definitely localize the resource files instead. The developers actually spend quite some time making the software localizable through resource files. And why not let the developers themselves recompile the software? That's not your job, and unless your word rate is extremely high that should not be part of the word rate. ▲ Collapse
| | | | | Check and change your system locale | Aug 19, 2010 |
Hello Cagou,
please note that the .NET framework itself is controlling whether a satellite assembly (like xxx.resources.dll) is loaded or not.
As my colleague from Passolo support already mentioned the missing signature of the satellite assembly could be one reason.
Another reason for this problem can be your system locale. You are in Australia, so I assume your system locale is English (Australia).
If this is true, the .NET framework will NO... See more Hello Cagou,
please note that the .NET framework itself is controlling whether a satellite assembly (like xxx.resources.dll) is loaded or not.
As my colleague from Passolo support already mentioned the missing signature of the satellite assembly could be one reason.
Another reason for this problem can be your system locale. You are in Australia, so I assume your system locale is English (Australia).
If this is true, the .NET framework will NOT load the French satellite assembly unless you change your system locale to French or unless the developers have overwritten the automatic selection of the .NET culture.
Maybe the developers have implemented a language selection in the software. This may fix the problem as it will usually overwrite the automatic selection of the .NET culture.
I will not comment on the resx or winres solution you proposed. For a resx based workflow the developers have to send all the resx files. You can translate them using Passolo but you can't test the software as you have to send back the translated resx files to the developers for compilation into a satellite assembly.
Hope this helps.
Achim
SDL Passolo Business Consultant ▲ Collapse
| | | | | Binary localization is best practice | Aug 19, 2010 |
Some additional comments from my side:
@Johnny
I disagree with
You should definitely localize the resource files instead. The developers actually spend quite some time making the software localizable through resource files.
Binary localization is always best practice, please read Issues and Benefits of Binary Localizatio... See more Some additional comments from my side:
@Johnny
I disagree with
You should definitely localize the resource files instead. The developers actually spend quite some time making the software localizable through resource files.
Binary localization is always best practice, please read Issues and Benefits of Binary Localization, published in MultiLingual Computing & Technology, Volume 11 Issue 4. This article was published in 2000 and describes EXE vs. RC approach. It's still true for .NET. You can also download and watch some of our free webinars on best practices for .NET localization.
Microsoft .NET is supporting some advanced UI design techniques like visual inheritance and/or the usage of 3rd party UI libraries. Information that is essential to support visual localization is stored in the assembly code ONLY (and NOT in resx files) and usually extracted and handled by software localization tools.
Having this in mind, binary localization is the only approach that offers correct visualization and the ability to change and adapt the .NET dialogs.
Yes, we claim to support binary .NET localization. The majority of our corporate .NET clients are successfully using this approach. The other part of the clients knows about the limitations of RESX localization and correctly deals with it.
@Cagou
It's up to the developers to decide on the localization approach. If the corporate client is sending you the binaries, you should localize them as expected.
Microsoft .NET localization is highly technical and clients that are just sending the binaries may expect too much. Translation vendors have internal localization engineers that are able to correctly prepare complex .NET projects which will be very difficult for a single freelance translator.
In your case I would expect that the corporate client owns a software localization tool and is correctly preparing the project for you instead of just throwing files over the wall.
Best regards
Achim ▲ Collapse
| | |
|
|
|
| Agree that binary localization is best practice | Aug 19, 2010 |
@Achim I agree with your point of view on best practices, but I think it was fairly clear that the original question from Cagou shows that no locaztion/engineering team is involved in the process, and that the customer do not have their own localization tool. As the developers are apparently ready to provide resource files I think that's the only way to go ahead for this specific project. The project won't get far if files are localized in a way that the development team can't handle.
| | | | Cagou
Australia
Local time: 08:41
English to French
+ ...
TOPIC STARTER | To clarify my situation | Aug 20, 2010 |
Johnny and Achim,
Thank you for your answers... though I'm not sure yet whether they'll help me through...
In my first message I explained my technical problem but from your answers I think I should also clarify why I really would like be able to recompile the target dlls myself.
Actually, I work (in-house) for the "corporate client". All development on the contrary is outsourced to various external IT companies. I usually do the French translation of the s... See more Johnny and Achim,
Thank you for your answers... though I'm not sure yet whether they'll help me through...
In my first message I explained my technical problem but from your answers I think I should also clarify why I really would like be able to recompile the target dlls myself.
Actually, I work (in-house) for the "corporate client". All development on the contrary is outsourced to various external IT companies. I usually do the French translation of the software and then coordinate the translation in other languages, which is done by our local subs around the world (and the Passolo "bundle" system is just perfect for that - thank you Achim! - as it prevents any messing up with the code, etc.). When I get the translations back I do all the debugging and checking, dialog adjustments, etc. on each language version... this is very time consuming and neither the translators nor the developers would do it (...and the developers' hour-rate is much more expensive than mine!).
Also the development contract specifies that the software has to be "localizable" not that it has to be "localized".
I've been doing this for the past 10 years using Passolo with various file formats and a variety of languages without any problem... which is why when this new project came around, I talked my management into buying the Passolo .NET add-in... and not feeling too good about not being able to use it.
Back to the technical issues
1) My system locale is French (just forgot to update my ProZ account, sorry! will do it ASAP).
2) I know Passolo can handle the resx files as well so that's my second best choice... although
a) that means I have to obtain the resx resources from the developers and
b) I am not 100% sure what my target files will be if I do this. Will I be able to generate a working target dll or will I end up with translated resx resources that I have to send back to the developers for compiling (not a good option in my case)?
3) The development team we're working with on this particular project seem to know as little about localization as I know about VS... BUT they've generated (with VS) "dummy" but functional French and Italian "xxx.resources.dlls"...
So I am quite convinced there must be a way to make this work... there must be just some tiny mistake somewhere... which is why I was seeking community help to try and track it down...
Cagou ▲ Collapse
| | | | Cagou
Australia
Local time: 08:41
English to French
+ ...
TOPIC STARTER | Problem solved | Aug 30, 2010 |
Hi all,
Just to let you know that I finally solved my problem 
There seemed to be a conflict between the original "French" satellite DLL made by the developpers and the "French" DLL that I produced with Passolo. Even though I deleted the original DLL and set Passolo's target rules to create the satellite DLL in the same folder, the original application would not load it correctly.
When I made a "Ger... See more Hi all,
Just to let you know that I finally solved my problem
There seemed to be a conflict between the original "French" satellite DLL made by the developpers and the "French" DLL that I produced with Passolo. Even though I deleted the original DLL and set Passolo's target rules to create the satellite DLL in the same folder, the original application would not load it correctly.
When I made a "German" DLL with Passolo, it all worked perfectly...
... so the ball was back in the developpers' field... and now everything is OK.
I am really relieved that it works... although a bit disappointed that there does not seem to be a lot of Passolo users on this forum...
I guess I am a bit nostalgic too of the "pre-SDL" Passolo support...
cagou ▲ Collapse
| | | | | Special Passolo forum | Aug 31, 2010 |
Hello Cagou,
good to hear the problem can be solved on your side. MS .NET localization is complex and sometimes it is hard to find out why things are going wrong.
I don't think that the support was better in "pre-SDL" times. I think today it's more regulated so that clients without PSMA may have problems to get support in a resonable time frame.
I agree that there are not so many SDL Passolo users in this forum. Since 5 years we are maintaining a special Pa... See more Hello Cagou,
good to hear the problem can be solved on your side. MS .NET localization is complex and sometimes it is hard to find out why things are going wrong.
I don't think that the support was better in "pre-SDL" times. I think today it's more regulated so that clients without PSMA may have problems to get support in a resonable time frame.
I agree that there are not so many SDL Passolo users in this forum. Since 5 years we are maintaining a special Passolo forum at http://forum.passolo.com
Achim ▲ Collapse
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Localization of a .NET application | 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 » |
| | Trados Studio 2022 Freelance | The leading translation software used by over 270,000 translators.
Designed with your feedback in mind, Trados Studio 2022 delivers an unrivalled, powerful desktop
and cloud solution, empowering you to work in the most efficient and cost-effective way.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
