RFC: Textpattern 5 ideas & feature requests

gaekwad · Yesterday 13:58:42

Some considerations for admin-side language strings, specifically around pophelp and their (its?) parity with textpacks.

Permit pophelps to be installed / updated in the way textpacks are currently.
Permit pophelps & textpacks to be deleted (see #1768 for existing issue)

Bloke · Yesterday 14:30:33

gaekwad wrote #340320:

Permit pophelps to be installed / updated in the way textpacks are currently.

Good idea. We should be able to do this. They’re XML and we have an importer so it shouldn’t be a stretch with some UI sprinkling.

Permit pophelps & textpacks to be deleted

That’s more problematic. Hiding unused ones via a toggle is simpler and less likely to confuse, imo. We can figure the best way, though.

jakob · Today 09:05:42

gaekwad wrote #340320:

Some considerations for admin-side language strings, specifically around pophelp and their (its?) parity with textpacks.

Permit pophelps to be installed / updated in the way textpacks are currently.

Permit pophelps & textpacks to be deleted (see #1768 for existing issue)

That’d be nice. I faked it in a recent update to etc_search by retrofitting a textpack string to the button.

Bloke · Today 09:36:03

Bloke wrote #340321:

[Pophelps are] XML and we have an importer so it shouldn’t be a stretch with some UI sprinkling.

It’d be great if we could handle this on the Languages panel.

All we really need is a way to indicate if a language has an update available for both (either?) pophelp and lang strings in the box.

Could we cover the install / update / reload using the existing button? So if either file is newer, it updates or installs them both?

Can anyone think of a situation where someone might want to install or remove only one and not the other?

The percentage still only applies to Textpack completion, as we’ve no way to gauge which elements require pophelp.

Edit: not sure about the manual additional strings box at the bottom. Could we accept either ini-style strings or XML there? Should de easy to detect which and handle accordingly.

This almost feels doable now :)

Last edited by Bloke (Today 09:39:12)

gaekwad · Today 13:30:26

Bloke wrote #340321:

That’s more problematic. Hiding unused ones via a toggle is simpler and less likely to confuse, imo. We can figure the best way, though.

Quick back of napkin maths shows the language packs + pophelps are currently ~3.5MB from a total of ~8MB in the expanded filesystem with /textpattern/setup/ present – so about 40% of the overall payload. Language packs is one area that likely keep growing, and it’s not something we can optimise easily.

Aside: are there any inherent risks associated with not uploading all the unused packs?

Bloke · Today 13:53:26

gaekwad wrote #340360:

are there any inherent risks associated with not uploading all the unused packs?

None whatsoever. The missing languages just won’t show up in the Languages panel (which is why we can’t “remove” them from the UI list without deleting the physical files… which means they’re then not available in future without downloading a pack and dropping it in the lang directory.)

Last edited by Bloke (Today 13:54:32)

Textpattern CMS

Textpattern CMS support forum

#97 Yesterday 13:58:42

Re: RFC: Textpattern 5 ideas & feature requests

#98 Yesterday 14:30:33

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340320:

#99 Today 09:05:42

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340320:

#100 Today 09:36:03

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #340321:

#101 Today 13:30:26

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #340321:

#102 Today 13:53:26

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340360:

Board footer