Support forum of the software localization tool Sisulizer


.NET, Delphi, ... - Sisulizer Localization Tool Support Home

Get in contact with the makers of Sisulizer.
Our forum is open for all questions around Sisulizer from customers and prospects.
Don't hesitate to register and ask. The Sisulizer team will answer ASAP.

Search     Help Home Sisulizer Website Download
Search by username
Not logged in - Login | Register 

 Moderated by: Sisusupport, Renate.Reinartz, Markus.Kreisel, Ilkka.Salmenius
New Topic Reply Printer Friendly
"Invalidated" status isn't updated during import - Usage - Three simple steps to localize - Technical Support (You need to be registered at the forum to write) - .NET, Delphi, ... - Sisulizer Localization Tool Support
AuthorPost
 Posted: Wed Apr 24th, 2019 01:47 pm
PM Private Upload Quote Reply
LeChuck
Member
 

Joined: Fri Jul 20th, 2007
Location:  
Posts: 7
Status: 
Offline
Hi,
we are facing a big problem with the way Sisulizer does (not) consider the "Invalidated" status of <lang> items during import. We use Sisulizer to localize our application for several languages. Which means we have one "original" Sisulizer project file that contains the executable as a source and, say, 5 target languages.For each target language we create an export (slmake exchange -lang:<targetlanguage>;) and give it to our translators. They work on these files (add translations for new things, update translations of changed items) and give us the files back. Then we import them back into our "original" sisulizer project file (slmake import).This process is automated for the most part and done by our build job script.
Our translators use the "red dots" (<Invalidated="1"> in the XML file) to check what things have changed and need to be updated. And can't stress how important this flag is for our translators. To give you an idea: the Sisulizer project contains 50000+ strings. We need a clean way for keeping track what was already updated and what still needs work.
When our translators work on their export files, the "Invalidated" status is cleared (either because the translator updated the translation of because the "Invalidated" state was manually explicitly removed).The theory was that this updated "Invalidated" state makes it back into the main file, so during the next export, only items that still require some work are marked as "invalidated". However, our translators complaint for quite a while now that the red dots re-appear for already cleared items.
I now took the time to check this and I can confirm this behavior. I've attached a very simplistic example ("Product.xml" is the main Sisulizer file, "ProductEn.xml" represents the exchange file) with just one resource. In the main file, both "en" and "pl" are set to 'Invalidated="1"'.
"ProductEn.xml" represents the English export file after a translator have worked on it. The translation was updated and Sisulizer removed the "Invalidated" tag.When I now runSlMake.exe import ProductEn.slp -lang:en -method:2 -overwrite:3 -e Product.slpto import this file, the translated "en" text will be updated, but the "Invalidated" flag for the English translation is not removed. Which means the next time this is exported again using
SlMake.exe exchange ProductEn.slp -lang:en -e Product.slpthe translator will see the item again has having changed, which is not the case.
To me this seems like a clear bug or at least a flaw in the process. How is this supposed to work? Can you please fix the behavior of "Invalidated"? You already have an option to update the "status" (best guess, translated, for review, etc.) during import. Maybe you can add an option to update the "invalidated" flag as well?(not sure though that an extra option is necessary. To me not importing the "invalidated" flag feels like a bug, to be honest)

Thanks,Markus

Back To Top PM Private Upload Quote Reply

 Posted: Wed Apr 24th, 2019 01:49 pm
PM Private Upload Quote Reply
LeChuck
Member
 

Joined: Fri Jul 20th, 2007
Location:  
Posts: 7
Status: 
Offline
Sorry, should have posted this in the "Bugs and Quirks in Sisulizer" section of this forum. Can I move it or can you please move it? Thanks, Markus

Back To Top PM Private Upload Quote Reply

 Posted: Wed Apr 24th, 2019 02:18 pm
PM Private Upload Quote Reply
Markus.Kreisel
Administrator


Joined: Sat Apr 8th, 2006
Location: Monschau, Germany
Posts: 3246
Status: 
Offline
Hi LeChuck,
the red, blue, yellow and green dots = row state are not meant to be maintained by the translator. Sisulizer uses these flags in the scan / scan for changes process.

Changing them manually is not recommended, except in rare cases where you want to overule this setting in the main project.

They are not meant to be used for conversation between translator and you. So they are not imported into your project. This would interfer with the next scan for changes process.
This behavior is by design.

Please use the translation state instead.
Markus




____________________
http://www.sisulizer.com - Three simple steps to localize
Back To Top PM Private Upload Quote Reply

 Posted: Wed Apr 24th, 2019 06:16 pm
PM Private Upload Quote Reply
LeChuck
Member
 

Joined: Fri Jul 20th, 2007
Location:  
Posts: 7
Status: 
Offline
Hi Markus,

thanks for the quick responds. I think I need some clarification then how the general process is supposed to work between a build server and translators. Which flag or signal can translators use to know what has changed and needs there attention?

By "translation state" do you mean "not translated", "best guess", "for review", etc? In that case I have to say that this doesn't work for us. Example: an item can have any of these states and when it's native text changes, Sisulizer keeps the state, but flags it as "changed" ("invalidated=1" in the slp file). To my understanding, Sisulizer has two types of (mostly independent) states: "translation status" and "row status" (new, unused, in use, changed). And then there's this "cell state" ("Invalidated" in the slp file). How can a translator know that an item that he/she has already translated (e.g. status "translated") has changed and needs to be checked again? It was my understanding that this is the purpose of these red dots (on cell level! not the row state!)
When would the red dots otherwise be reset? And why does Sisulizer remove the red dot (on cell level) when the translator edits the cell? It really feels like an indicator for "hey, this needs your attention".

Just to clarify: Sisulizer shows red dots for the whole row ("row status") and in cells. The former ("row status"), to my understanding, is represented in the .slp file by the "state" attribute of the element. The latter ("cell status"?) is controlled by the "invalidated" attribute of the element.
And I'm talking about the cell status, not the (overall) row state.

Here's our scenario: we use subversion and we develop in trunk. Every 10 weeks we create a version branch. The version branch is build by a job on the build server. Sisulizer is part of the build script. We scan the compiled binaries, we check if there are new files from the translators (if so, we import them), then we build the satellite assemblies (it's a C# project), then we generate new export files so that the translators have the latest version.
Over the next weeks the version is tested and either our quality team or translators might find issues in the native texts. This is reported back to the developers, the native texts are fixed in the code and committed into the branch. Build job will generate new binaries and also new export files for our translators, so they see the latest changes to the native resources. It's also possible that new string resources are added which need to be translated. We might add a new argument to a resource string which has to be added to the localized strings as well. Therefore our translators need some way to see what strings have changed and need to be checked. Right now, they often use (or tried to use) the "Invalidated" filter. They edit the cells with red dots and save. Our build job picks it up and imports. On next export these items are still marked as "invalidated" although they have been properly updated by the translators. When, then, would this "invalidated" state be removed?

I hope I could clarify the problem. If not, please don't hesitate to ask for more details.

Thanks,
Markus

Back To Top PM Private Upload Quote Reply

 Posted: Wed Apr 24th, 2019 06:26 pm
PM Private Upload Quote Reply
Markus.Kreisel
Administrator


Joined: Sat Apr 8th, 2006
Location: Monschau, Germany
Posts: 3246
Status: 
Offline
The red dots are set by Sisulizer to show changed items. It is not meant to be set by translators. Therefore it is not imported back to the main project.

Yes, the translation states are "not translated", "best guess", "for review" etc. These are meant to set by translating. In addition you can add comments to the cells to communicate.

Sorry, but we can't change the product in a way that the row statuses are used for a different use.

Thanks for your understanding

Markus



____________________
http://www.sisulizer.com - Three simple steps to localize
Back To Top PM Private Upload Quote Reply

 Posted: Thu Apr 25th, 2019 06:47 am
PM Private Upload Quote Reply
LeChuck
Member
 

Joined: Fri Jul 20th, 2007
Location:  
Posts: 7
Status: 
Offline
Hallo Markus,
I'm sorry. I think this is a big misunderstanding. It's not about communicating with translators and nobody is changing the "row state" manually.
I'm talking about the invalidated state. The CHM documentation gives this explanation for "Invalidated" (highlights by me):
"Invalidated translations

When Sisulizer scan a source and it finds that either context of a row or original row has been changed (most likely developer has modified the resource value) it changes the row status to Changed and invalidates all translations. This means the current translation value is kept but they are marked as Invalidated. To validate translation the user has to check if it still valid and either modify the translation (this automatically validates it) or right clicking the translation and choosing Translation | Invalidated."
My point is the different experience if you work as the sole translator directly with the main project file versus working via exchange/import. I've added a screenshot to illustrate it.Let's say I'm a translator and I can work directly with the main Sisulizer project file. Someone gives me a new binary, I scan it, I see all resources as "not translated" and I translate all of them ("Phase 1"). By default, Sisulizer sets the "Status" of translated items to "Translated". It's my initial pass and I want to review my translations later, so for now I'm content with the "Translated" status (I will set them to "Complete" at a later time).
Over the next days, developers make some changes to the resources. So I do a Rescan ("Phase 2a"). For changed values, the "Complete" status is changed to "For Review", but all other status remain the same. But I want to see how much has changed and fix what needs fixing. So I filter for "Invalidated" items.By simply editing the cells, Sisulizer automatically makes these items valid again (or I could choose to manually set some items to valid again) as documented in the CHM (Phase 2b)
I save my changed. If I open the file again, it's still the same state. All works fine and as expected.
This workflow changes when "slmake exchange/import" are used. Let's assume I'm working remote and the company sends me an exchange file.If we now jump to "Phase 2a" the modified items will be marked as "Invalidated", just as expected. I edit these items with by Sisulizer Translator Edition and here too, Sisulizer removes the "invalidated" state as soon as I start editing a cell. just as expected. Now I save and send this file back to the company. They import it.
A couple of days later they do a new exchange and send me the new file. And all items that I just updated a couple of days ago are marked as invalidated again.This wouldn't happen when I edit directly on the main file. But I think it should behave the same as if I had worked directly on the main file.
Markus


Attachment: 2019-04-25 SisulizerInvalidatedIssues.png (Downloaded 6 times)

Back To Top PM Private Upload Quote Reply

Current time is 01:19 pm  
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > "Invalidated" status isn't updated during import



WowUltra modified by Sisulizer Copyright © 2007-18 by Jim Hale - Based on WowBB Copyright © 2003-2006 Aycan Gulez

Impress - Privacy statement

Sisulizer software localization tool - Three simple steps to localize