Better way to set new textpack related data?

NicolasGraph · 2017-11-09 10:04:05

Hi,
I guess it is the right place to ask…
In the example below, should I prefer this:

gtxt(
    skin_step_failure',
    array(
        '{skin}' => $this->skin,
        '{step}' => 'import',
    )
);

to lighten the txp_lang table by using the same textpack item for different steps, or:

gtxt(skin_import_failure', array('{skin}' => $this->skin));

for clarity and code shortness?

Last edited by NicolasGraph (2017-11-09 10:05:49)

etc · 2017-11-09 10:21:20

Unless skin_step_failure string contains {step} pattern, I see no difference..?

NicolasGraph · 2017-11-09 10:51:33

etc wrote #307732:

Unless skin_step_failure string contains {step} pattern, I see no difference..?

Yes, that’s the point.
skin_step_failure create only one new item; it is only one row in the DB and only one translation.
skin_import_failure, skin_edit_failure, etc. are clearer if translations are missing, but I maybe should not care about that?

etc · 2017-11-09 10:56:27

Ah, ok. The less strings the better imo, but I’m the last person to ask UX-wise.

NicolasGraph · 2017-11-09 11:01:42

etc wrote #307736:

Ah, ok. The less strings the better imo, but I’m the last person to ask UX-wise.

Thanks; Phil maybe has a UX based advice?
Otherwise I will keep the first option, using less strings.

philwareham · 2017-11-09 11:56:22

Not sure I understand. In the first example how would you proposed the actually translation text to be formatted? If you use…

skin_step_failure => Theme {skin} failed at {step} stage.

…then isn’t {step} hardcoded in English – such as ‘import’ and ‘edit’? That would not be desirable.

So, although yes it’s extra translation work and database increase, the unique string names will have to be used (as has been done historically everywhere in the admin side).

If I’ve not understood correctly, then my apologies.

NicolasGraph · 2017-11-09 12:31:19

philwareham wrote #307744:

Not sure I understand. In the first example how would you proposed the actually translation text to be formatted? If you use…

skin_step_failure => Theme {skin} failed at {step} stage....

…then isn’t {step} hardcoded in English – such as ‘import’ and ‘edit’?

Obviously, you’re right! Is my brain that rusty?!

Last edited by NicolasGraph (2017-11-09 12:31:54)

philwareham · 2017-11-09 12:37:05

No worries. New Textpack strings are OK to add as long as we keep them to essential items only. In this case the extra strings are warranted.

I’ve pruned quite a number of legacy unused strings out of the Textpacks at 4.7 now we have the luxury of breaking away from the old RPC server anyway.

NicolasGraph · 2017-11-09 13:04:30

philwareham wrote #307747:

I’ve pruned quite a number of legacy unused strings out of the Textpacks at 4.7 now we have the luxury of breaking away from the old RPC server anyway.

Thanks for that.

Bloke · 2017-11-09 17:23:57

I had a similar thought the other night and mused over whether it would be good if we had this kind of thing:

panel_action => {item} <strong>{name}</strong> {action}

So we could use Style default updated, Language Deutsch installed, and so forth, saving ourselves a tonne of specific strings.

Then I realised that the structure of that string – its word order – is very English-centric and would likely deliver nonsensical results in other languages, so quickly talked myself out of the idea! While reducing the quantity of language strings is a noble goal, there’s an argument to be made for specifics where necessary.

However, now that languages are on the cusp of being bundled into core (yay!) I think we need to focus on improving load_lang() and being clever about how we handle strings. load_lang() is a resource hog and happens on every page. We now have a ‘local’ copy in the filesystem of every string in the lang directory. Does that mean we don’t need to “install” a language at all? i.e. Txp will automatically ship with all languages available (for core strings at least), so can we repurpose the Languages panel in future versions to be a ‘string manager’ or translation aid?

If we beef up the L10n\Lang.php methods (as I’ve been doing the last few weeks) and improve them so we can extract data better and more efficiently, or organise it better, then maybe we can eke some more speed out of Txp by parallel processing: fetching essential content from the DB and offloading string manipulation to the filesystem, perhaps?

The only unknown is what to do with custom/plugin strings. Installing/removing files in the filesystem is messy so maybe we need to rethink this a bit?

Anyone got any neat ideas on how we might evolve this to shed ourselves of the legacy RPC overheads that are still prevalent in the filesystem-based approach?

makss · 2017-11-09 21:14:15

philwareham wrote #307744:

skin_step_failure => Theme {skin} failed at {step} stage....

…then isn’t {step} hardcoded in English – such as ‘import’ and ‘edit’? That would not be desirable.

possible variant:

gTxt(
    skin_step_failure',
    array(
        '{skin}' => $this->skin,
        '{step}' => gTxt('import'),
    )
);

makss · 2017-11-09 21:55:53

Bloke wrote #307753:

The only unknown is what to do with custom/plugin strings. Installing/removing files in the filesystem is messy so maybe we need to rethink this a bit?

Which existing plugins support multiple languages? I would like to test one idea on real plugins.

Textpattern CMS

Textpattern CMS support forum

#1 2017-11-09 10:04:05