|
All you need is:
string.Parse(theMessageString, theParam1, theParam2)
Works the same as Console.Out.WriteLine(theMessageString, theParam1, theParam2)
Just put the param references({0},{1}) where you normally would within the string and store it that way. string.Parse will work with the text retrieved from the resource file too!
Trevor
|
|
|
|
|
<<each "submit"="" in="" all="" the="" forms="" translates="" into="" something="" like="">>
This is one typical mistake for home-brew localization solutions: reusing the same string in several places.
This is bad internationalization practice, because the same word might be translated differently. Examples: "Print" is translated into French as "Imprimer" or "Impression", depending if the thing is a command (button) or descriptive elemente(label, title). This is true for most Latin languages. Example: "Scan" is translated differently if it is about scanning the disk or scanning a piece of paper. You might say: yes, but if I know is a button, always, and is the same action, then is ok. No. Example: "New" can be translated with a masculin or a feminin form, so the English buttons creating "new stuff" end up with different translations. In Japanese the some attributes are translated differently depending on the propoertions of the object described (the same attribute is translated differently for a pen or a ball)
And if you add together all problems in all languages, is just not possible.
Second problem is about the use of resx files. Yes, they are inconvenient to work with. But localization is about more than string labels.
- label/dialog size: languages can be very long, sometimes 3-4 times longer than the English. Some languages will have to be abbreviated (lowering the translation quality), others will have huge spaces
- fonts: some languages require you to change the font and font size (CCJK and Thai need bigger font than Western European languages)
- mirroring: Arabic and Hebrew require "flipping" the dialogs
- images/colors: these are also localizable
- context: there are localization tools that can preview the dialog stored in resx. Translating in context increases quality and decreases price (less bugs to fix later)
You will say "it can be done," I will say "yes, for 3,4, max 10 languages". But the string only solution does not scale!
I don't like resx files either, but they are a necessary evel. The good news is that the pain is alleviated by tools that automatically handle resx files for localization (leveraging, keep and validate resizing, validate ampersands, etc)
|
|
|
|
|
Hello..
Mihai Nita wrote: <<each "submit"="" in="" all="" the="" forms="" translates="" into="" something="" like="">>
i am saying IF you have the submit button in all the forms , if you have submit for a label you can still use a different string for that
like GetString("101") for the submitbutton
and GetString("102") for submit label or what ever you want
And if the string is differntly translated in different language
You definetly have to change the User interface accordingly , you can neither help that in .Resx approach can you ?
in both approach you have to change the size of the common button which will show different length text in different language.
Wel here atleast you can be assured that THIS reusability can be done for all the 90% text which does not involves customization
Mihai Nita wrote: typical mistake for home-brew localization solutions
Well i must say that this approach is not home-brew this used to be a standard approach since the ages of Visual studio
ResGen is an application which comes in the tool package even with .Net
So creating a resource file and using it is not a home-brew solution at all
Mihai Nita wrote: And if you add together all problems in all languages, is just not possible.
Well i think all these customization issues or problems are common to both the approach and not just the resource file approach
Mihai Nita wrote: But localization is about more than string labels.
- label/dialog size: languages can be very long, sometimes 3-4 times longer than the English. Some languages will have to be abbreviated (lowering the translation quality), others will have huge spaces
Mihai Nita wrote: - fonts: some languages require you to change the font and font size (CCJK and Thai need bigger font than Western European languages)
Both of these are again the user interface cutomization issue which is in both not just in this approach
Mihai Nita wrote: - images/colors: these are also localizable
can be done in this approach also easily as in the example
All the problems you have mentioned here is common to both
Mihai Nita wrote: But the string only solution does not scale!
Well i have added a language support to three Very Big application (windows as well as web) using this approach in three different language and found it very easiliy adaptable , i am still doing it for all the dynamic upgrades which are going on in the simplest manner.
Not to mention that i started with the .resx file approach and gone crazy after sometime.
I can say that .resx file approach may give you more power over the application at the cost of complexity but its definetly not easily scalable and extensible the way this approach is. And ofcourse it all depends on the programmer himself he can get things done with both the approach
|
|
|
|
|
Quartz... wrote: if you have submit for a label you can still use a different string for that
This was the point. You MUST ALLWAYS use a different string.
Quartz... wrote: not easily scalable and extensible the way this approach is
The developer cannot decide now if is ok for the languages or not, two months down the road.
You don't want to go back to code just because you translate in another language.
And no, resx does not help you here either.
This was a stand-alone point, not "pro resx"
Point is, is not ok to do this kind of reusability. You feel like you save 30 cents, but it might cost you 5 dolars
Quartz... wrote: Well i must say that this approach is not home-brew this used to be a standard approach since the ages of Visual studio
Yes, it ResGen is an old beast. But the mechanism is designed for stand alone strings (error messages), not to take them and "push" them in forms.
This is abuse/misuse.
If I come up with a way to store messages in a C header file, is a home-brew "solution" (and a bad one), even if the .h files are not new.
Quartz... wrote: Well i think all these customization issues or problems are common to both the approach and not just the resource file approach
The difference is big. If you have resx files, the customization is part of the normal localization tasks.
With your approach, there is one set of forms, but my examples imply the need of different resx files (mirroring, fonts, etc.).
You mean you still keep separate resx files for each language? Then what is the gain?
Quartz... wrote: in three different language and found it very easiliy adaptable
I am talking scalable as number of languages. Please read my post. 3 languages is nothing.
Let's talk again when you get to 30.
Quartz... wrote: but its definetly not easily scalable and extensible the way this approach is.
I think we are talking about different kind of scalability.
It seems I don't fully understand your method.
You mean you still have separate resx files for the languages? This is the only way to "customize" them and to cover languages that require different fonts or mirroring.
If this is the case, then what is the advantage of this approach?
You still have to maintain 30 sets of complete resx files.
You delete a button in English, you still have to delete it in 30 resx files, AND IN THE CODE (which is not the case with the "standard" way)
And the initial coding, instead of "drag a button in the visual form editor" you also have to write code to load the string.
You cannot visualy resize the dialogs, because the strings get in the labels only at runtime.
The only advantage is that you translate on property files instead of resx files.
No big deal. There are tools out there to handle this. Even visual tools, where translators can see the context.
Or you can write something to convert a resx to other format, send out for translation and put it back in resx. You have standard .NET classes to read/write resx files.
|
|
|
|
|
Mihai Nita wrote: This was the point. You MUST ALLWAYS use a different string.
WHY ? Can you explain it ,
if you can do it with one common string in one file for 20 forms
Why do you want to maintain that string for each of the instance in 20 different files ?
There is a clear Maintenability advantage in the first approach i think
Mihai Nita wrote: You feel like you save 30 cents, but it might cost you 5 dolars
I mean you agree you save atleast 30 cents but you don't explain HOW it might cost you 5 dollars.
Mihai Nita wrote: Yes, it ResGen is an old beast. But the mechanism is designed for stand alone strings (error messages), not to take them and "push" them in forms.
This is abuse/misuse.
If I come up with a way to store messages in a C header file, is a home-brew "solution" (and a bad one), even if the .h files are not new.
i will suggest you dig more on ResGen
ResGen does the samething what you are doing with .Resx files there is not a single difference
.Resx approach you are making the resource for EACH forms and .Resource file is a Single File for the whole application
THERE IS NO DIFFERENCE AT ALL ResGen can also create .resx files
you can start here to look msdn[^]
Mihai Nita wrote: You mean you still keep separate resx files for each language? Then what is the gain?
Mihai Nita wrote: I am talking scalable as number of languages. Please read my post. 3 languages is nothing.
Let's talk again when you get to 30.
Ok let me explain you what is the GAIN in more simple way
For simplicity assume you have Winform application with 20 forms
and you have to make it a multiple language application FOR 30 language ok ?
Using .resx Approach ,
You will create 30 .Resx files for each Form
So a total of 30 x 20 = 600 .resx files you have to manage
And using .Resource approach which is actually using totally same technology
you create ONLY 30 Resource files for each language
and actually each files is a keyword value pair text files which can be much more easily managed
Mihai Nita wrote: It seems I don't fully understand your method.
You mean you still have separate resx files for the languages? This is the only way to "customize" them and to cover languages that require different fonts or mirroring.
If this is the case, then what is the advantage of this approach?
I think you might wanna just try the sample application in the article and try to create a similar one with .Resx files approach, and let me know what you think after that
nice brainstorming
cheers
Raj
|
|
|
|
|
Quartz... wrote: WHY ? Can you explain it ,
if you can do it with one common string in one file for 20 forms
I think I have explained why you cannot use the same string: because you don't know the requirements of all the languages you are going to translate into.
Quartz... wrote: but you don't explain HOW it might cost you 5 dollars
When 3 months after you think you ended development, you released 5 languages, you started developing the next version, you discover that a new language needs to change something that you hard-coded in a certain way. So you stop development to the next version, fix the code (which affect the released languages). And it might get more expensive than $5
Quartz... wrote: ResGen does the samething what you are doing with .Resx files there is not a single difference
There is a big defference: resx files store way more than strings. I think I have explain this.
Coordinates, fonts, colors, you name it.
If you generate that from properties, then you will also have to go back and change the code to load it.
Quartz... wrote:
For simplicity assume you have Winform application with 20 forms
and you have to make it a multiple language application FOR 30 language ok ?
Using .resx Approach ,
You will create 30 .Resx files for each Form
So a total of 30 x 20 = 600 .resx files you have to manage
And using .Resource approach which is actually using totally same technology
you create ONLY 30 Resource files for each language
and actually each files is a keyword value pair text files which can be much more easily managed
So, your big problems is a file count? Like you are going to handle this manualy C'mon!
You can automate this in one afternoon (if you don't want to look for a tool that does it already).
Quartz... wrote: I think you might wanna just try the sample application in the article and try to create a similar one with .Resx files approach, and let me know what you think after that
I am working in localization and internationalization for the last 10 years, did hundreds of projects for more than a hundred companies. Believe me, I did it, and I know what I am talking about.
Yes, there are things I have about resx files, and the fact that there is one file per form is one of them. But what you do is not the solution, the solution is automating the process. Then you can run your leveraging scripts on a folder tree, not on a file. And at that point it does not matter that you have 300 forms in 300 resx files or in one.
|
|
|
|
|
Mihai Nita wrote: Yes, there are things I have about resx files,
Correction: <<yes, there="" are="" things="" i="" hate="" about="" resx="" files="">>
|
|
|
|
|
Mihai Nita wrote: localization and internationalization for the last 10 years
Mihai Nita wrote: did hundreds of projects
Mihai Nita wrote: for more than a hundred companies
ofcourse i cannot argue with you , i don't have that much experience
do let me know if you have any suggestion to improve this
thanks
|
|
|
|
|
Quartz... wrote: of course i cannot argue with you
No need to argue
Quartz... wrote: do let me know if you have any suggestion to improve this
In my experience what works best is an automated leveraging system working on resx files.
The leveraging system scans folders for localizable files (resx and properties)
If the translation tools used can natively handle resx files, is is best to leave the files "as is" (and just import the changed ones). This is because such tools can show a WYSIWYG view, which helps translation a lot.
If not, it extracts the localizable strings in a file format that is easy to localize. It can be your key-value format, but it is best if it is some file format that is standard for localization (because standard localization tools will handle it with no problems) and support Unicode. Java properties or some XML format are in this class.
When the translated files are back, the leveragins system can produce the new set of translated files. It can also leverage resizing for dialogs that are not changed (or changed very little):
OldEnglish + NewEnglish + OldLocalized + TranslatedDelta => NewLocalized + ResizingReport
This is pretty much the idea.
I cannot make this kind of tools available (developed for my employer), but they are not that difficult to create. There is public API to read/write resx files, and properties are also easy.
|
|
|
|
|
If you use a nice modern tool like the layout control from DevExpress, the sizing issues and font issues are automated so all these points made by the complainer are even more incorrect.
Opening and editing every form is rediculous!
A few forms might need some tweaking, but requiring all forms to be edited for all languages OMG!
Again, take an issue where you have a problem 5% of the time and excuse me (not so bright people) change the entire process and geometrically increase the work for all forms, all of the time to accomodate the 5% problem.
This is a great soluion: use it and correct the 5% of forms that need tweaking and let the other "brilliant" people correct every form , every time as they live in their world of unable to imagine change and accomplish the same goals over a much greater period of time.
|
|
|
|
|
twesterd wrote: If you use a nice modern tool like the layout control from DevExpress
Do you mean that DevExpress changes the fonts to Japanese fonts for Japanese translation and so on? And font sizes? I am familiar with DevExpress and don't remember this feature.
And it does not solve issues like colors, images, mirroring, context.
If you know what you are doing there is a certain level of auto-layout in .NET 2.0 itself, no need to spend extra on tools, or to edit all the forms.
The point was: .NET has a standard way to deal with localization, just use it, don't invent another.
Anyway, if you have never had a big application translated in more than 5 languages, you probably cannot judge what works well and what not.
|
|
|
|
|
No - it does not set Japanese fonts - the font is stored in the resource file, so are the separate images, and so are color settings (assuming you apply themes).
What the control does is allow dynamic loading of controls and the layout of the controls. The VS layout control is not even close. You allow a user to modify a single text file for the language variations regarding messages. (I also have all regex paterns, etc localized and in config files - no element is hard-coded into the form).
Run the application and open the form - the layout can be adjusted after the app is compiled or before, at design time, or runtime. You run the application and open each form for QA/QC check where each form must pass certain tests (like open sub forms etc) to verify all elements are displaying properly. If they are incorrect, a layoout dialog can open and you make your adjustment - live. (drag and drop and set properties for each item on the form). Save the settings and its done.
Furthermore, if you do happen to make a mistake, the end-user can adjust the layout anyway and they always do. They can show/hide available controls/fields/images, change the size, change the order, change the font, change the color, etc. So, each user can setup each form, individually, how they want and save their changes.
I'm sorry, your methods sound like techniques from 5 yrs ago.
Seriously,
Downlaod a trial and play with the layout. DevExpress doesn't specify the best localizing techniques, but you can see how the layout is freely adjustable at runtime and design time.
You can save the layouts for defaults and you can see how the end-user can adjust layouts. You can also allow user to apply some changes for some controls and not others (its configurable). Frankly, its being devloped for dynamic forms and their ExpressApp which is in Beta does just that, but, currently, you still need to give it some initial help (less work than what you describe - I have been there). Can your users setup their forms however they want? Mine can!
|
|
|
|
|
twesterd wrote: the font is stored in the resource file, so are the separate images, and so are color settings
Ok, so what is the point? The article tries to avoid storing this kind of stuff in resource files.
You say that my comment does not apply to the article, then come back with a 3rd party library that solves only one of my 4 or 5 points.
Extracting text does not scale properly for many languages. It is not about scaling the forms.
The rest is just marketing blah-blah for DevExpress.
I have it, played with it, cute, but it does not solve much here.
Have you read the article, or just trying to promote DevExpress?
twesterd wrote: I'm sorry, your methods sound like techniques from 5 yrs ago.
And I'm sorry, your methods sound like you never localized anything in more that 3 languages
I will close the discussion here, unless you come with something relevant to this article.
|
|
|
|
|
The main point is not to use resource files for every form that requires that you open the designer and manually tweak them. The point is that the actual text is maintained in a single resource file.
Frankly, it can be any external resource from .dll, but language specific resource files can be maintained in one that be easuily updated in in all 500+ forms with massive editing and a much greater tendency towards error.
As far as Devexpress - do what you will. I noticed that you skipped the point of end-user modificatio - fairly significant point.
You are clearly a person that has a "my way rules" and you resist change greatly.
Please, what are the reasons for using a separate resource file for every form?
Hmm you mentioned layout, graphics, and fonts.
I do not say that the fonts are maintained in a rresx file for every form, they are NOT. This a a great difference.
Your layout (I assume since I did not get a reply) is not dynamic, nor user configurable. What you set is what they get.
Hmm if you have language specifc graphics (which should be avoided , but is sometimes necessary), are yu suggesting the images be stored in seaparate files for every form (wow big library you must have). Oh , if you mean adjusting layout, then again your end-users are stuck aren't they?
Seriously, what advanatge is there with your method? It slower, it requires duplicate entries, it doesn't allow for end-user modification, any mistakes in layout require a rebuild, the size of the application is larger, it requires developers to make changes at design-time.
A for this article... its WAY WAY better to have a consolidated file. And just because your way gets the job done does not mean others don;t get it done better.
It's simple, What are the advantages to design the localization your way?
|
|
|
|
|
twesterd wrote: not to use resource files for every form
100% agree with you here. Storing one form per file, and then require a separate file for strings is one of the .NET WTF decisions I am complaining a lot.
The classical Win resources are way better.
Thing is, it is better than the idea to "divorce" the text from layout.
Because of localization tools you don't have to *manually* update the 500+ forms in 500+ files.
twesterd wrote: a person that has a "my way rules" and you resist change greatly
No, I am a person that did l10n and i18n work for more than 10 years, on hundreds of projects, big and small. So I know that works, what breaks, and why.
I am willing to take a look at new ways of doing things. But yours is not new, I have seen it before, and it does no scale well for many languages.
twesterd wrote: Please, what are the reasons for using a separate resource file for every form?
Not advocating for this. It is bad. But it is the standard way, better that your alternative, so I am willing to live with it.
twesterd wrote: nor user configurable. What you set is what they get
This is what they get with the code, so why being different about UI is different?
To believe that regular users care about tweaking the UI is a typical programmer mistake. They don't care, they don't want to change the UI. They want you to make it right, because they pay for it.
twesterd wrote: it requires duplicate entries
This is good, because the same English string has to be translated differently depending on context. Example: "Print" is translated in French as "Imprimer" (for buttons/manus/commands) or "Impression" (for labels, titles, etc.)
twesterd wrote: any mistakes in layout require a rebuild
Of one language only. This is done by localizers, not by developers. And it affects one language only.
A layout mistake with your approach touches the main application.
And it is easier to make a mistake in a form that is supposed to work on all languages, with no text in place, than make a mistake in a French form with all the French strings in place.
twesterd wrote: requires developers to make changes at design-time
No. It require localizers to make changes. The changes affect one language only, the developers are out of the loop.
twesterd wrote: What are the advantages to design the localization your way?
I think I have explained this in all my previous posts.
|
|
|
|
|
Awesome approach. I had been working on a globalization solution for an app and after seeing this, may take a 180. Very simple and straightforward, not to mention continuously adaptable!
Thanks for the great example!
RABB17
"Nothing fancy needed, please just solve all our problems as quickly as possible."
|
|
|
|
|
Thanks for your comment,
i am glad you find it useful, do let me know if you come across any furthur imrovement
cheers
Raj
|
|
|
|
|
Raj,
If you send me your e-mail I'll send you the source and demo for a resource editor/creator I wrote that keeps everything in culture-specific format.
RABB17
"Nothing fancy needed, please just solve all our problems as quickly as possible."
|
|
|
|
|
that sounds cool
here it is studyrajesh[At]hotmail[dot]com
|
|
|
|
|
Thanks..
I like it as well..
.NET Rules
|
|
|
|
|
|
Why don't we use the default enabled resources for each form or user control with a default view as a standard and go with it?
Why reinventing the wheel ?!!
Ahmed Amin El-Morali
S/W Developer
EGYPT
|
|
|
|
|
Well first of all thanks for your comment
morali2k wrote: Why don't we use the default enabled resources for each form or user control with a default view as a standard and go with it?
For three simple reasons
1. Maintainability
Assuming you are taking .resx files approach
Take a simple scenario, By mistake you have a wrong translation for a "Submit" button for a
say german language. The original translation is "Einreichen" but you initially missed the
last n and now you have "Einreiche" instead of "Einreichen" for submit button through out your
application
What you can do to resolve this,
a. You have to go to each forms and change the resource
file of the form
b. Compile the exe again creating the german dll
and redistribute the whole exe with setup including the new dll
On the other hand if you use a single resource file as in the article ,
Each "Submit" in all the forms translates into something like
ResourceManager.GetString("101")
If tha translation is wrong just
1. update the initial german text file
2. Resgen it and create a resource file
3. Over write your existing resource file by the updated resource file
you are done
Redistribution just redistribute the light weight resource file
and you EXE will automaticall update the submit button every where
2. Extensibility
You have to add another language say latino
.resx file approach go to each form create resx file for Latino
compile and create latino dll
With Sigle Resource file approach
Create another text file with latino translation as shown in example above
Resgen it and Add a menu option for Latino
you are done. You can have a latino menu option even earlier and add teh resource file later
you won't even need to re compile
3. Dynamic UI changes
With resource file you can have a drop down menu instead of the radio button in the example
and change the complete UI on the fly to whichever language you fancy
With .resx and dll approach you have to start the application with that localized dll
i think you might be able to dynamically change the UI but it will be much more complex.
another not that important reason is, Resource file approach create light weight .Resources files where as .resx creates dll for each language.
well i hope this answers your queries, well if want to go by standard approach you can definetly get better results but not as fast as this approach will give you (thats why 20 minutes )
morali2k wrote: Why reinventing the wheel ?!!
Well ResGen has been there since the ages of Visual Studio 6.0 and this approach is quite popular since then , i am not reinventing the wheel just using the one, i feel is better
Raj
|
|
|
|
|
Hi,
I'm really not agree with you.
1. if your application size is too large, the embedded resources are greatly more maintainable.
2. if you create one resource file for each project, for the resx files you can create resources.designer.cs file which contains static methods for each string resource; so you can easily call properties.Resources.TXT1 instead of ResourceManager.GetString("101") and get rid of mistyped strings.
3. also you can edit the resx file using .net UI and there is no need to use resgen or any other tools and copy and paste and ....
just type your name and value of your resource file. the resources.designer.cs file will be updated automatically and you can use resources.* in your code.
also you have intellisense with you.
in resources.designer.cs:
///
/// Looks up a localized string similar to LPR Search.
///
internal static string LPR_Search {
get
{
return ResourceManager.GetString("LPR_Search", resourceCulture);
}
}
in yourcode:
node = new TreeNode(Resources.LPR_Search, 1, 1);
regards,
Hamid Rostami
|
|
|
|
|
Hamid Rostami wrote: if your application size is too large, the embedded resources are greatly more maintainable.
I definetly agree that .resx with .Net UI and resources.designer.cs along with intellisense gives the complete control to the User,
When i first started the language support , i was completely baffled by "the .resx" approach , it was haunting and so i abondoned that
used the ResGen approach and was easily able to get things going at the first place without worrying about a lot of things.
Well i wil do an application completely in .Resx approach then will be able to compare with this approach.
So far i am able to manage easily three large application in multiple language very easily and that what gave me the idea of this article
Thanks for your comment,
Raj
|
|
|
|
|