RTL languages and DB (=double byte ?) languages can be rendered as well, as all data within Passolo is handled as UTF-16. I found a special issue with RTL languages. It seems that they are rendered correctly, but wrongly aligned to the left instead of right. I logged this case, but Passolo is still correctly calculating the width of the string.

Talking about the different modes will be a huge topic. I would suggest reading https://learn.microsoft.com/en-us/windows/win32/gdi/windows-gdi 

Thanks once again Achim, and I noticed the same thing, tested yesterday with Arabic. Good to know that it should work, and yes, I know that the mode topic is a bit challenging, thanks for the article. I still have one issue that I am not sure if it can be solved, the issue with parameters/variables within the string, e.g. %1s or similar. Our client has provided different dynamic length values for these (one string can contain one or two variables, %1s and %2s, and they may have different lengths depending on the string context. Have you found a way to include these in the text renderer check? I was thinking of replacing the variable with a string that matches the dynamic length value when running the check.

Jouni

The TextRenderer is a simple configurable method to render translated strings with special fonts and check if these strings fit into a defined space. It has its limitations, and the usage of placeholders is one of them. The reason for this is that the required information cannot be provided by development, or because the content of the placeholders is far too dynamic.

Assume that the string is The %1s will be deleted. Passolo shows %1s as a literal string and calculates the width of the literal string, which is not correct.

If %1s will be filled with file, folder, or hard drive you need to know if these strings appear in your project, and you need to link them to the current string entry saying that %1s will be filled with some other IDs from your project. Is your client or your developer able to deliver such information? In my carrier I once saw such a huge Excel sheet that provided this information, unfortunately in a very unorganized way so that a software wasn’t able to evaluate it.

If the content is completely dynamic, the use case is even more complex. You have to pay %1s in taxes. is a good example. The amount may vary from $1.00 to 123.456,00 EUR and there is no easy way to define the maximum width for such a placeholder.

For sure, such features could be implemented, but I think it won’t make sense to implement it into the generic TextRenderer because it is far too rare and typically very user-specific. The question is how big the pain point is for the client or developer, and whether they are willing to invest into a custom solution that solves more problems that the generic TextRenderer does.

The TextRenderer is a simple configurable method to render translated strings with special fonts and check if these strings fit into a defined space. It has its limitations, and the usage of placeholders is one of them. The reason for this is that the required information cannot be provided by development, or because the content of the placeholders is far too dynamic.

Assume that the string is The %1s will be deleted. Passolo shows %1s as a literal string and calculates the width of the literal string, which is not correct.

If %1s will be filled with file, folder, or hard drive you need to know if these strings appear in your project, and you need to link them to the current string entry saying that %1s will be filled with some other IDs from your project. Is your client or your developer able to deliver such information? In my carrier I once saw such a huge Excel sheet that provided this information, unfortunately in a very unorganized way so that a software wasn’t able to evaluate it.

If the content is completely dynamic, the use case is even more complex. You have to pay %1s in taxes. is a good example. The amount may vary from $1.00 to 123.456,00 EUR and there is no easy way to define the maximum width for such a placeholder.

For sure, such features could be implemented, but I think it won’t make sense to implement it into the generic TextRenderer because it is far too rare and typically very user-specific. The question is how big the pain point is for the client or developer, and whether they are willing to invest into a custom solution that solves more problems that the generic TextRenderer does.