LP_XMLConverter Libpacks and password protected objects

[Piotr Dobrowolski]

Since some instructions on howto deal with translations in libpack is now published... I just wanted to try with existing library packed to lcf.

But I am hitting the wall hard way: LP_XMLConverter does not process libpack when the lcf that is part of the source folder contains password protected files...so the questions is: who the ... this functionality is for, maybe I do something wrong, but if the translation is only for open files then there is no point. I just wanted to experiment with the file system (files/folders) I have my own translation system inside the library.

[Barry Kelly]

Maybe if the password protection didn't hide the parameter list in the objects, maybe it would work then?

I am assuming that the mapping tables need access to the parameters of the objects, and that has something to do with it.

I have always said that password protection should not hide the parameter list anyway, so we can edit the default values for 3rd party protected objects to suit our custom templates.

The global libraries and mapping tool would have been great for this, but obviously not if you can't make a package from protected objects anyway.

Barry.

[Piotr Dobrowolski]

The probable problem is that whenever a project containing libpack is saved as pla then it changes the parameters to the permanent translated to desired language.

So there could be a flag "do not interfere" with the content, so making pla would save default language.

or maybe limited translation to the file system: for me that would fit my needs, as I have my own translation system driven in MVO.

Edit:

But: so what, when it works with libpack as folder. Then pla will make default language as it would with regular lcf, and would have default path as in lcf

[NBGheikki]

This is quite unfortunate news, since it makes using libpacks for commercial projects impossible without leaking proprietary code to the outside world. I do hope password protection will be supported at some point. It can't be technically impossible since even now AC must have some way to access the code despite encryption.

[Piotr Dobrowolski]

It is possible to use "libpacks as folders" with commercial projects, but it might be cumbersome as the user has to switch this option on.

It is not good as for user friendliness as the libpack container does.

The libpacks are with us since version 26 (25 r2?)...but as no manual for it, but some parameters descriptions in LP_XMLConverter/? - if we had some manuals earlier and tried it: probably this topic would be raised at least year ago...

Real use is possible since 27 as the commands for the localization choosing and "use folders as libpacks" are there. (tested and it works).

I hope all profesional GDLers will try using all possible channels to enlighten GS developers. I hope it will change their minds.

[ZsuzsannaB]

Thank you for all of your feedback; you have made some valid points.

Making password protection possible for libpacks is on our roadmap, we will try to prioritize it going forward. 🙂