Non-localizable string and resource naming

This is a place to discuss how to adapt mojoPortal to the needs of different cultures. Before asking questions here please first review the localization documentation.

This thread is closed to new posts. You must sign in to post in the forums.
11/8/2006 4:41:13 AM
Gravatar
Total Posts 488

Non-localizable string and resource naming

The following string cannot be localized:

1. /Admin/PageLayout.aspx: default new module name


The following resources violate the naming convention:

1. PageLayoutPageNameLabel used only on \Admin\PageSettings.aspx
2. PageLayoutMetaSettingsLabel used only on \Admin\PageSettings.aspx
3. PageLayoutIncludeInMenuLabel used only on \Admin\PageSettings.aspx


Could you fix it?

P.S. Why not using App_LocalResources instead of App_GlobalResources for such resources?
11/8/2006 6:29:49 AM
Gravatar
Total Posts 18439

Re: Non-localizable string and resource naming

Hi Alexander,

These issues are now corrected in svn/branches/joesandbox2

The reason I prefer using App_GlobalResources instead of App_LocalResources, is when you use local resource you have a separate resx file for each page or user control. I think this is more messy to maintain and it is easier for a translater to go through just one resx file to contribute a new translation. If there were separate fiels it will be more work to find the missing keys.

Also, prior to .NET 2.0 (and still currently in the 1.x version of mojoPortal), I was storing localized strings in a .config file for each language so when I converted that to the new 2.0 .NET localization model it was easier to do it all in one file per language instead of having to go through every page and control and create a new resx file.

Cheers,

Joe
11/8/2006 10:14:44 PM
Gravatar
Total Posts 488

Re: Non-localizable string and resource naming

Thanks for the fix.

I cannot agree with your opinion that it is easier to translate the single file.

The idea is how the translation is being performed.

If the translation is performed by copying the english file and translating all the strings in it one-by-one without looking at the pages they are present on - of course, you are right. But in my opinion it's really impossible to produce accurate translation of the page in such a way.

When I perform the translation I do the following. I open 2 browser windows: with the original and the translated variants of the page. I look at the page and think how to translate these strings in the context of this particular page to make the whole translation accurate. After that I find the specified string in the resource file and enter the translated version.
In this case it's much easier to find the string in the small file than to find it in a big one.
It's also easier not to forget any help or error messages not visible by default - as the file is much smaller, I can see that there are some untranslated strings on this form easier.

Plus, when using separate files:
1. Issues like naming convention violation mentioned above become impossible because of no need of this naming convention.
2. If you do not see the string in the short file you can be sure it is not stored in resources - now I need to find all such strings in the big file and make sure they belong to other pages (because of the possibility of naming convention to be violated).
3. It's easier to translate separate feature modules without translating the whole portal (if I do not need all the modules). If I write my own feature module, I can provide some translations to it without violating the portal translation convention. It's also easier to see if some new modules are not translated at all.


It's all my IMHO. :)
11/9/2006 2:24:06 AM
Gravatar
Total Posts 488

Re: Non-localizable string and resource naming

And some more (forwarding your fix):

1. In the help window the button "close" at the bottom is not localizeable.

2. The following resources now seem not to be used anywhere:
- PageLayoutIncludeInMenuLabel
- PageLayoutMetaSettingsLabel

3. The old resource PageLayoutPageNameLabel is still used on /Admin/PageSettings.aspx (it was used twice, only one of the usages has been replaced to PageSettingsPageNameLabel).

And, finally, a question. I have got some more corrections to the russian translation. Is it better to send the patches incrementally, or to finish it and send as a whole patch?
11/9/2006 3:19:07 AM
Gravatar
Total Posts 18439

Re: Non-localizable string and resource naming


1. is localizable, the key is iboxCloseWindow, there is also one for iboxLoading, these are set at the top of /ClientScript/ibox.js.aspx

2. ok, I removed those from the english resource file, I'm not really concerned much about a few stray keys that are not used but I suppose it is good to keep the english one clean since others will most likely use it for translation

3. fixed

probably better to fix them all and send one more patch, but no problem if you see any you missed and need to send again a few times, I'm very glad to have updated resources.

Thanks,

Joe
11/9/2006 3:26:49 AM
Gravatar
Total Posts 488

Re: Non-localizable string and resource naming

1. Sorry, it really is.
11/9/2006 4:16:11 AM
Gravatar
Total Posts 488

Re: Non-localizable string and resource naming

But I do not see any message while the window is opening, only the animated circle.
11/9/2006 4:20:05 AM
Gravatar
Total Posts 18439

Re: Non-localizable string and resource naming

I think most of the time it loads so fast you won't see the message. The same thing happens for me.
11/9/2006 4:22:26 AM
Gravatar
Total Posts 488

Re: Non-localizable string and resource naming

You are right.

But today it happened so that I saw the circle for about 5 seconds. There was no word there.
11/9/2006 4:27:24 AM
Gravatar
Total Posts 18439

Re: Non-localizable string and resource naming

If you think it might be a bug feel free to have a look and try and fix it. It could possibly be a styling issue where it just blends in with the background or something.
You must sign in to post in the forums. This thread is closed to new posts.