More than one localization per country

Topics: Project Management Forum, User Forum
Jan 8, 2008 at 1:34 PM

We have different Dutch translations for different types of education.
The terminology for primary education can differ quite a bit from higher education or vocational training.
How can we get these translations codesigned?
Coordinator
Jan 8, 2008 at 7:45 PM
The source code as of 1.3.x can be built and signed locally. There is no longer a private key, the signing key is included in the source code and used as part of the "nmake" build script.
Jan 8, 2008 at 8:45 PM

One more question:
I made my translation on version 1.3.0.1
Now 1.3.0.2 will be available soon (and more to come).
Have you made any changes in the XML-files, or can I reuse the 1.3.0.1 files with the 1.3.0.2 version?
I have changed the versioninfo to 1.3.0.2
I hope I do not have to follow the whole procedue from the start (too good for my RSI ;-)).
As far as I can see, it works, but I'd like to be sure.
Coordinator
Jan 8, 2008 at 9:53 PM
There have been no changes to the XML files between 1.2.x and 1.3.0.x. There may be some changes in 1.3.1.

Unfortunately, I'm not very familiar with the localization process, I'm still working on coming up to speed on other aspects of the SLK codebase. If you let me know how the localization process worked for you and what changes you needed to make to get it to work with the 1.3.0.2 build, I'd be happy to post this information to the wiki page. You're not the first person to ask about getting a localized 1.3.x build, but you are the first person to try and modify the files to make it work :-)

- jcb
Jan 9, 2008 at 6:47 AM
As mentioned JayBeavers, 1.3.x is built with new key. So I think we need to re-sign resource DLLs with the new key for 1.3.x binaries as following steps.

Create XML files for translation from 1.3.x binaries. (e.g. Microsoft.SharePointLearningKit.dll)
> Localize Extract Microsoft.SharePointLearningKit.dll SharePointLearningKit.xml

Translate the XML files or copy and paste both <key> and <keytoken> sections to the existing XMLs (1.2.x) on source code from extracted XMLs above.

Generate resource files.
> Localize Generate SharePointLearningKit.xml

Re-sign the resource files.
> sn.exe -R Microsoft.SharePointLearningKit.resources.dll SlkKey.snk


See source code for the details.
Localization tools: <Source code>\Tools\LocalizationGuide
Translated XMLs: <Source code>\Tools\LocalizationGuide\TranslatedXMLs
Key file: <Source code>\Src\Shared\ SlkKey.snk

Hope this helps you.
Jan 9, 2008 at 1:11 PM

I too ran into this issue today and the good news is that it is fixed now. The fix does something similar to what is described above. Since we no longer have re-signing, I fixed this by doing away with the <key> and <keytoken> tags in the XMLs and changing the generator code to create the satellite assemblies (the localization dlls) with the new SlkKey.snk.

Since the language packs are different from the earlier ones (due to the change in the public key), their versions have been incremented and the next release will bear version 1.1.0.0
SLK 1.0, 1.1, 1.2 releases work with the 1.0.799.0 language packs. All releases after SLK 1.3.0 will work with the 1.1.0.0 language packs.
Jan 10, 2008 at 10:05 AM
Thanks VandanaPonnuru for the updates. I did quick deployment test and verified SLK 1.3 work with the 1.1 language packs.
Jan 10, 2008 at 10:50 AM
In the 1033 translatedXML the culture.txt = en-US while in the XML-files <assembly culture="fr" name="Microsoft.LearningComponents.Storage.resources" version="1.1.0.0">

Jan 10, 2008 at 10:57 AM
Edited Jan 13, 2008 at 6:45 PM
Unfortunately I see many differences between my translated files (so probably 1.0.0.0 based) , which means a lot of copy-paste actions ;-(( to correct this.
Is it a safe procedure now, to use the translated XML-files in the directory drop 29530\Slk\Tools\LocalizationGuide\TranslatedXMLs\1033 as an original and paste my translations in?
Or will there be other changes?

Correction: The contents are the same. Only the ordering of the blocks has changed. So, not as bad as I thought ;-)
Jan 10, 2008 at 11:04 AM
Changes need to be applied to:
drop 29530\Slk\Tools\LocalizationGuide\Doc\Microsoft SLK LocalizationGuide.doc
drop 29530\Doc\LanguagePacks\InstallInstructions.txt
drop 29530\Doc\LanguagePacks\ReleaseNotes.txt

is dontLocalize.txt still accurate?
Jan 10, 2008 at 11:07 AM
LocalisationGuide:
4) Localize the <Translation> elements in the .xml files and edit the “culture” attribute at the top of each file to reflect the culture of the localized language.
Note: only global cultures should be used (e.g. fr instead of fr-FR).

In TranslatedXMLs 1041 <assembly culture="ja-JP" name="Microsoft.LearningComponents.resources" version="1.1.0.0">

I did not check all the other files.
Jan 10, 2008 at 11:10 AM
dontLocalize mentions:

DefaultSlkLearnerPermissionName
DefaultSlkInstructorPermissionName

Is there a specific reason for this?
If I update my Dutch documentation, can I use SLKleerkracht and SLKleerling as a translation?
Jan 11, 2008 at 8:01 AM
Edited Jan 16, 2008 at 1:07 PM


VandanaPonnuru wrote:

Since the language packs are different from the earlier ones (due to the change in the public key), their versions have been incremented and the next release will bear version 1.1.0.0
SLK 1.0, 1.1, 1.2 releases work with the 1.0.799.0 language packs. All releases after SLK 1.3.0 will work with the 1.1.0.0 language packs.


Jay mentions: There may be some changes in 1.3.1.
When is this release planned and will it mean updating all translations again?
Or will changes be in a clearly defined section?

second question:
afterSLK 1.3.0 will work with the 1.1.0.0 language packs
Does this mean, that 1.3.0.2 still works with the 1.0.0.0 version?
I can't get the combination 1.3.0.2 and 1.1.0.0 working.
Coordinator
Jan 29, 2008 at 4:34 PM

Vandana is the language packs expert, but I don't know of any features coming in 1.3.1 that will interfere with the work she just completed for the 1.1.0.0 language packs.