|
|||
|
|||
| Moderated by: Renate.Reinartz, Markus.Kreisel, Jaakko.Salmenius, Ilkka.Salmenius | ||
| Author | Post | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
rvacaru Member
|
Hi, me again  We have a help system based on FlowDocuments (a XAML file / help topic) and we'd like to use Sisulizer as translation tool for this. That means we prepare a .slp project with a flat list of XAML files and we send it to the translation agency together with the Sisulizer free edition. They translate the text and send us the project back. Sounds good... but... parsing XAML files is not perfect sometimes. In the next days we will try to parse all our files and to collect issues/bugs. One of them I have already, I will privately upload the XAML page. The Paragraph content is not retrieved (only content of Runs). Strangely for other documents, the Paragraph content is correctly retrieved. Regards Radu |
||||||||||
|
Janusz Grzybek Super Moderator 
|
Hello, Thank you for file. We'll check it. In the next days we will try to parse all our files and to collect issues/bugs. Thanks in advance . We are always interested in improving of our software.Best regards, Janusz |
||||||||||
|
rvacaru Member
|
One thing I have noticed. The standard TextBlock control in WPF supports Inlines. You can parse its Content similar as the FlowDocument's Paragraph items. |
||||||||||
|
rvacaru Member
|
Ok, it seems to be clear. I am not sure how you parse the XAML files (Regex or XML-based) but for a FlowDocument it seems you are skipping the default Inlines (as I already stated in my post above for TextBlock). If you fix that ASAP we can immediately use Sisulizer to localize FlowDocuments and that would be awesome. Plus that your statistics will be more accurate (which is vital for a translation tool). Currently I count words/chars separately (getting very close to what Word is reporting) but you should report it accurately too. Example:
Hope to get a fix soon! Last edited on Fri Mar 12th, 2010 09:32 am by rvacaru |
||||||||||
|
Markus.Kreisel Administrator 
|
Hi,Plus that your statistics will be more accurate (which is vital for a translation tool). Currently I count words/chars separately (getting very close to what Word is reporting) but you should report it accurately too. Word is counting some things in a different way. Have you tried e.g. AnyCount. You might get another different result. The problem is: what is a word. Is 5 a word? Is <b> a word? A translator might say yes since he has to take care of both. What i want to say, that it is more than pure counting. Try with a smaller project that you can count manually. You will see the problems while counting. I did that a few times because I wondered about the results compared to Word or AnyCount and I always found Sisulizer counting right regarding rules relevant to translators. If Sisulizer does not find the FlowDocument in your sample, than it also will not count that :-) Perhaps this is the difference? Markus |
||||||||||
|
rvacaru Member
|
My main problem is not the word counting The main problem is that Sisulizer is NOT parsing the XAML correctly, so even if you have a state-of-the-art word counting mechanism if your counting source is wrong then the results will be obviously wrong For example if I copy the text from the simple FlowDocument I posted above in Word I get: 9 words. Sisulizer says 3 words. Guess who's right :D PS: Of course 5 is a word. And < b > is not a word, it is a token that the translator should not touch in order to preserve the correct formatting Last edited on Fri Mar 12th, 2010 10:47 am by rvacaru |
||||||||||
|
Janusz Grzybek Super Moderator
|
rvacaru wrote: My main problem is not the word counting I forwarded this issue to our developers. Of course, we let you know about all news related to FlowDocuments support. Best regards, Janusz |
||||||||||
|
rvacaru Member
|
Thank you! I am looking forward to seeing it fixed as it will save us a lot of time (and money)  |
||||||||||
|
rvacaru Member
|
Any news from the WPF (XAML / FlowDocuments) front? Incomplete support is like no support from the productive usage point of view ... |
||||||||||
|
Markus.Kreisel Administrator
|
Hi, Some issues simply take a bit longer. I'll ask R&D if there is some way to speed this issue up. Markus |
||||||||||
|
Markus.Kreisel Administrator
|
Hi, I have feedback from R&D. It is more complicated and it needs more time to solve. It is definitly not forgotten. Markus |
||||||||||
|
Jaakko.Salmenius Administrator 
|
Current Sisulizer does not support FlowDocuments. I have to implement it and I am implementing it at the moment. However this is a new stuff for us and I first have to learn how they work. After that I can complete support for flor documents. Jaakko |
||||||||||
|
Jaakko.Salmenius Administrator
|
I can not get flow content support for build 301 (thise week) but most likely for 302 (in April). Jaakko |
||||||||||
|
rvacaru Member
|
Thank you very much for the update! It is important for us to know that you are working on it and it will be supported. Thanks again and good luck with the implementation |
||||||||||
|
Janusz Grzybek Super Moderator
|
Hello, I sent you PM. Regards, Janusz |
||||||||||
|
rvacaru Member
|
From our point of view FlowDocuments topic is not so critical anymore. I implemented our own mini-tool to translate our FlowDocuments (using MS Translator/Google) and it works very well for us. |
||||||||||
Sisulizer software localization tool - Three simple steps to localize