Please publish latest translation templates

[BigMike]

In the translation files, there’s the variable %APPNAME% which is replaced by “PowerArchiver 2018”.
But the language texts suggest, that it should only be “PowerArchiver”. That’s not really a translation issue, since even the English text is wrong.
See the example:

There’s no “PowerArchiver 2018 9.xx”, the hint should tell me, that I need PowerArchiver 9.xx or later.

I found more occurences where “2018” doesn’t fit, mostly in hints. On some occurences (e.g. the window titles) it makes sense, but isn’t really needed.

[spwolf]

@BigMike said in %APPNAME% should not contain the version:

In the translation files, there’s the variable %APPNAME% which is replaced by “PowerArchiver 2018”.
But the language texts suggest, that it should only be “PowerArchiver”. That’s not really a translation issue, since even the English text is wrong.
See the example:

There’s no “PowerArchiver 2018 9.xx”, the hint should tell me, that I need PowerArchiver 9.xx or later.

I found more occurences where “2018” doesn’t fit, mostly in hints. On some occurences (e.g. the window titles) it makes sense, but isn’t really needed.

problem with changing these, for instance to PowerArchiver, is that all translations of that part become invalid and then show in English, as specific text is translated (vs specific “line” in translation text).

It helps when there are already translated text which we can then easily reuse, but also it messes up things like this since if we changed it, all of that tip would shown in english in 32 languages.

[BigMike]

Sorry, but are you sure?
This is a screenshot of the translation tool:

The strings contain %APPNAME% which is replaced by PowerArchiver 2018
Why should the translated strings break when you change the behavior and replace %APPNAME% by PowerArchiver?

[spwolf]

@BigMike said in %APPNAME% should not contain the version:

Sorry, but are you sure?
This is a screenshot of the translation tool:

The strings contain %APPNAME% which is replaced by PowerArchiver 2018
Why should the translated strings break when you change the behavior and replace %APPNAME% by PowerArchiver?

Translated strings from your side - in actual translations would not break. You can do that on your side and it will work great.

What I meant was fixing it on our side, in original translation files, because it is not the same string anymore when you replace %APPNAME% to PowerArchiver…

So we cant easily correct it from our side for all translations, but yes, you can do it from your side in your files.

Good?

[BigMike]

@spwolf Ok, actually, I meant, is it really intended by your side, that %APPNAME% is replaced at runtime by PowerArchiver 2018?
I mean even the US-en language (and any other which contains %APPNAME%) will be wrong if it’s translated according to the given original text.

Yes, I can fix this myself if I replace %APPNAME% by plain text PowerArchiver, but this won’t fix the other translations. Also I will get a warning when the original string contains a variable and the translation doesn’t so I don’t like this solution very much…

[spwolf]

@BigMike said in %APPNAME% should not contain the version:

@spwolf Ok, actually, I meant, is it really intended by your side, that %APPNAME% is replaced at runtime by PowerArchiver 2018?
I mean even the US-en language (and any other which contains %APPNAME%) will be wrong if it’s translated according to the given original text.

Yes, I can fix this myself if I replace %APPNAME% by plain text PowerArchiver, but this won’t fix the other translations. Also I will get a warning when the original string contains a variable and the translation doesn’t so I don’t like this solution very much…

yeah, because it is replaced in many other cases where it make sense… so to pick these few where it looks bad and replace it with PowerArchiver, instead of %APPNAME%, then it will be all new translation for translators.

I guess we will see if we can somehow tag these “bad” ones and replace them with PowerArchiver at runtime. What other places did you notice where it looks bad?

thanks!

[BigMike]

Ok, while I noticed some places, where it’s wrong and some where it could be useful, I wasn’t aware, that it’s needed in some places. Most cases are related to compatibility hints.

I didn’t review all, because it’s used in many places, so these are just examples:

pas.resourcestring.“Disabled” - disables encryption for ZIP archives.
“PK 2.04g” - creates standard ZIP archives, with weak encryption but readable by all Zip utilities.
“AES 128-bits” - creates encrypted ZIP archives with AES 128-bit encryption, readable by newer Zip utilities (%APPNAME% 9.xx, PkZip 8.xx, WinZip 9.xx, etc).
“AES 192-bits” - creates encrypted ZIP archives with AES 192-bit encryption, readable by newer Zip utilities (%APPNAME% 9.xx, PkZip 8.xx, WinZip 9.xx, etc).
“AES 256-bits” - creates encrypted ZIP archives with AES 256-bit encryption, readable by newer Zip utilities (%APPNAME% 9.xx, PkZip 8.xx, WinZip 9.xx, etc).
Please Note: While PK 2.04g encryption can be read by all Zip utilities, this method uses weak encryption that can be broken.
You should use .PAE encryption, 7-Zip or ZIP AES encryption if you require real security. We do not recommend using both 7-Zip/ZIP Encryption and .PAE encryption at the same time.
Will be evaluated to PowerArchiver 2018 9.xx

pas.resourcestring.“PkZip 4.5” - makes PkZip 4.5 compatible archives, readable by newer versions of all popular compression utilities.
naming scheme: test.zip.zip, test.zip.z01, test.zip.z02, etc.
“PkZip/PA 7.0” - makes archives that are compatible with both PkZip and %APPNAME% 7.xx.
naming scheme: test.zip, test.z01, test.z02, etc.
“%APPNAME% (older versions) Compatible” - creates archives that are compatible with %APPNAME% 6.xx or earlier.Last file needs to be opened in order for PA to recognize spanned archive. This Mode is only recommended for use when you need to send files to people with %APPNAME% 6.xx or lower.
naming scheme: test001.zip, test002.zip, etc.
Will evaluate to PowerArchiver 2018 (older versions), PowerArchiver 2018 7.xx and PowerArchiver 2018 6.xx

pas.resourcestring.%APPNAME% Backup 2014
Will evaluate to PowerArchiver 2018 Backup 2014 which is contradictory…

pas.resourcestring.%APPNAME% Backup Lite (Free for personal use) 2014
same here

pas.resourcestring.%APPNAME% Encryption Suite 2014
same here

pas.resourcestring.</b> attachment. We recommend that you <a TARGET=“_blank” HREF=“http://www.%APPNAME%.com”>download
Here you are referring to www.PowerArchiver 2018.com, which actually isn’t an allowed web address at all.

pas.resourcestring.LZMA - strong compression method, up to 50% better than deflate. Compatible only with %APPNAME%, WinZip 12 and 7-Zip.
States, that only PowerArchiver 2018 is compatible with LZMA archives.

pas.resourcestring.%APPNAME% (older versions) Compatible
“PowerArchiver 2018 (older versions)” doesn’t make sense also…

While in most cases, I think it doesn’t really matter:
If there’s a “PowerArchiver 2018 Backup” or “PowerArchiver Backup” or a “PowerArchiver 2018 Shortcut” or “PowerArchiver Shortcut”

[BigMike]

By the way, do you have the possibility to make “automatic mass changes” to all translation files?

Actually instead of adding some magic code to PowerArchiver, which handles %APPNAME% in different ways, would be either

• introducing two variables like %SHORTAPPNAME% and %FULLAPPNAME%
• replacing %APPNAME% by plain string PowerArchiver on the occurences where it is needed.

This helps the translators as they know, how the string will be translated in the end. But both will break the translation files.

[spwolf]

@BigMike said in %APPNAME% should not contain the version:

By the way, do you have the possibility to make “automatic mass changes” to all translation files?

Actually instead of adding some magic code to PowerArchiver, which handles %APPNAME% in different ways, would be either

• introducing two variables like %SHORTAPPNAME% and %FULLAPPNAME%
• replacing %APPNAME% by plain string PowerArchiver on the occurences where it is needed.

This helps the translators as they know, how the string will be translated in the end. But both will break the translation files.

we can change some things at runtime, it is not pretty… removing version year should be fine.
Otherwise yes, changing it in original translation file means all new string.

[BigMike]

@spwolf It’s not pretty on your side to implement - and it’s not pretty on my side to work with, if I don’t know how the string will finally look in the application.

I can’t imagine a good and easy way to keep track of the handled strings. I mean I don’t know if all of them are still used in the application and where they are used. So basically I would need to report all strings if I find one in the application (wrong for sure) and everytime I find one in the translation (maybe wrong, maybe already handled - which can only be checked by you). And not only me, but also any other translator and user.

But on the other hand, changing it in my translation file will only change the German translation of PowerArchiver, changes done by you will correct all localized versions.

It will be pretty easy to keep track of the changed strings, if I make them in the localization, as they appear in the category “Problems/Warning”, in case I replace %APPNAME% by PowerArchiver. That would be easy for me, but doesn’t help for other translations, until you look into the translation files and adapt the other translations (or ask the translators to do so).

Your decision…