|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Bugs and Quirks in Sisulizer > How to work with custom resources in Unicode
|
|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Bugs and Quirks in Sisulizer > How to work with custom resources in Unicode
|
| Moderated by: Renate.Reinartz, Markus.Kreisel, Jaakko.Salmenius, Ilkka.Salmenius |
|
||||||||||||||||
| How to work with custom resources in Unicode - Bugs and Quirks in Sisulizer - Technical Support (You need to be registered at the forum to write) - .NET, Delphi, ... - Sisulizer Localization Tool Support | |||||||||||||||||
| Author | Post | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
|
DJB_MEC Member
|
I have a Win32 application written in MFC using Visual Studio C++ which was using 8bit characters and Sisulizer 1.6.x was used to localise the application. The source code texts requiring translation are processed and stored in the resource as custom resources and within Sisulizer setting the property of each of these custom resources to "string" allowed the translation to be performed and resource Dlls generated. Now the source code has been changed to support Unicode UTF-16 and the resource generation process updated so the resource contains little endian UTF-16 text. That part works fine but Sisulizer doesn't seem to recognise that the text is in UTF-16 format. I have now tried an evaluation copy of Sisulizer 2008 Enterprise edition and that provides the new feature to set the resource type to "String" and set the string type to UTF-16 little endian. When that change is made and a rescan done the display of the string doesn't seem to take this into account and is incorrect and shows as shown in the attached file. The resource DLL files generated also seem to be treating the custom resources as though the were still 8bit characters and result in incorrect text display in the application. Can you tell me if this is a configuration or use problem on my part or an issue with Sisulizer. Attachment: sisu.jpg (Downloaded 29 times)
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Markus.Kreisel Administrator 
|
Hi, please make sure that you have the latest Sisulizer V2008 build. For build 279 the history.txt says: "Windows RC: Unicode resource files can also be scanned" If that does not help please send your .slp and the resource to support (at) sisulizer.fi. Please add a description how we can reproduce the issue with your sample. Markus
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
DJB_MEC Member
|
Markus, I am testing the latest version of Sisilizer 2008, build 129. I have just noted that Sisulizer can do what is required but would be very tedious. The next comments refer to the attached image. The folder 368, as an example, has the format set to "string" and UTF-16 little endian but this does not seem to effect the sub-items. I noticed that the sub-items have properties and one is "Use folder format", this appears not to work as expected. When I uncheck this the dialog shows settings as "string" and UTF-16 little endian, as per the folder setting, and on OK'ing and a rescan the text is represented as expected and the output resource Dll generated has these entries correct. As the resource contains over 1000 texts in this format changing each sub-item is not desriable. The format used is the folder represents a source file and the sub-item is the line number in the source. Setting the format on a folder basis is OK as these don't change often. Attachment: sisu2.JPG (Downloaded 23 times)
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Markus.Kreisel Administrator
|
>> I am testing the latest version of Sisilizer 2008, build 129. 129 is pretty old. Do you mean 279? Can you please send the files to support (at) sisulizer.fi. We need a reproducible situation to make sure we speak about the same issue. With you files I can try myself if the folder property is not propagated to the rows and open an internal case. Markus
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
DJB_MEC Member
|
Markus, Sorry, yes I meant 279. File has been sent. Hope that helps. David
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Janusz Grzybek Super Moderator 
|
Hello David, Thank you for files. Below is solution: Right click on e.g. Emperor.exe > 256 > 191 node (this is example from your first screenshot). Next select properties from context menu and uncheck “Use folder format” option. Next select options as on below screenshot and re-scan project. Best regards, Janusz Attachment: screen.png (Downloaded 22 times)
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Janusz Grzybek Super Moderator
|
Sorry David, I tested your issue before I read your second post.The folder 368, as an example, has the format set to "string" and UTF-16 little endian but this does not seem to effect the sub-items. I noticed that the sub-items have properties and one is "Use folder format", this appears not to work as expected. When I uncheck this the dialog shows settings as "string" and UTF-16 little endian, as per the folder setting, and on OK'ing and a rescan the text is represented as expected and the output resource Dll generated has these entries correct. As the resource contains over 1000 texts in this format changing each sub-item is not desriable. Unfortunately, Sisulizer haven’t any automatic method for change this option at once for all sub-nodes. I will ask about changing that our R&D. Janusz
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
DJB_MEC Member
|
Thanks for the reply, hopefully the change can be made so that the parent folder settings are taken by the sub-item as indicated by the "use folder format" checkbox. That would make the guy that manages the releases and translations quite happy but he is resigned to doing all 1500 or so texts as he has done it before apparently. Interestingly on checking an old 1.6.13 release on creating a new project with the executable it recognised the custom resouces as unicode and displayed correctly when the string setting was set but insisted on creating the resource Dlls with 8bit characters for any translated texts. The version in use at the moment, 1.6.23, shows the text as in my first post so doesn't seem to recognise unicode as the earlier version did.
|
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Jaakko.Salmenius Administrator
|
I fixed this bug in build 280. The reason was that Sisulizer did not pass the text file format specified in the folder settings to the node but node tried to the default format that is ty to detect the format. The text resources were in UTF-16 but because there was no BOM (byte order mark) Sisulizer could not detect the format correctly but used Ansi. The new build comes out in few days. Jaakko
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| Current time is 05:59 pm | |
| .NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Bugs and Quirks in Sisulizer > How to work with custom resources in Unicode | |
Sisulizer software localization tool - Three simple steps to localize
