Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Better way to set new textpack related data?

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)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#2 2017-11-09 10:21:20

etc
Developer
Registered: 2010-11-11
Posts: 2,949
Website

Re: Better way to set new textpack related data?

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


etc_[ query | search | pagination | date | tree | cache ]

Offline

#3 2017-11-09 10:51:33

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Better way to set new textpack related data?

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?


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#4 2017-11-09 10:56:27

etc
Developer
Registered: 2010-11-11
Posts: 2,949
Website

Re: Better way to set new textpack related data?

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


etc_[ query | search | pagination | date | tree | cache ]

Offline

#5 2017-11-09 11:01:42

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Better way to set new textpack related data?

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.


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#6 2017-11-09 11:56:22

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,093
Website

Re: Better way to set new textpack related data?

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.

Offline

#7 2017-11-09 12:31:19

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Better way to set new textpack related data?

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)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#8 2017-11-09 12:37:05

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,093
Website

Re: Better way to set new textpack related data?

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.

Offline

#9 2017-11-09 13:04:30

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Better way to set new textpack related data?

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.


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#10 2017-11-09 17:23:57

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,458
Website

Re: Better way to set new textpack related data?

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?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB