Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2014-12-16 17:11:56

Pat64
Plugin Author
From: France
Registered: 2005-12-12
Posts: 1,595
GitHub Twitter

Textpacks problems

Hi Devs ;)

Here is 2 problems seen with Textpacks strings:

## Date/Time of Textpacks upload aren’t right:

## I haven’t translations strings for rah_wrach plugin (installation with french translation first, no good results after I uploaded the English Textpacks):


Patrick.

Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.

Offline

#2 2014-12-16 23:16:53

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Textpacks problems

Pat64 wrote #286646:

Date/Time of Textpacks upload aren’t right

No. But it’s deliberate. The comment from the install_textpack() routine regarding this behaviour reads:

“Created strings get a well-known static modification date set in the past. This is done to avoid tampering with lastmod dates used for RPC server interactions, caching and update checks.”

Without this step, Textpattern wouldn’t (currently) know if a core Textpack update was required, since it checks the newest timestamp of any lang string and uses that to determine if an update is available. Installing your own strings (or a plugin doing so) and setting the datestamp “now” would break this.

Longer term, the lang table now has an “owner” column, which means we could differentiate between core strings and user/plugin strings and thus be able to use real datestamps. On top of this, reliance on the RPC server for strings is planned to be phased out of the critical path so the datestamps will potentially carry less importance than they do now.

I haven’t translations strings for rah_wrach plugin (installation with french translation first, no good results after I uploaded the English Textpacks)

Check the Textpack itself. Look at the top of the block and check the line that starts with:

#@language

Textpacks can target a nominated language, so if a plugin defines language designators for each block of strings, and you don’t happen to have any of those languages installed, you’ll get no strings.

Omitting the language marker means “these strings are for the default language” so the usual advice is for plugins to not specify the language designator for one set of strings (usually English). That means everyone gets (at least) the English strings, regardless of which language they have installed, and if the plugin contains specific strings for the exact language you are using, they will be loaded over the top of these ‘base’ English strings.

Does that help at all?


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

#3 2014-12-17 07:34:24

Pat64
Plugin Author
From: France
Registered: 2005-12-12
Posts: 1,595
GitHub Twitter

Re: Textpacks problems

Ok. Thanks lot Stef ;)

My first attempt was to inject the default (#Default language) language Textpack from Jukka’s Github file:

https://raw.githubusercontent.com/gocom/rah_wrach/master/textpacks/en-gb.textpack

When I check my data base, the table (txp_lang) wasn’t populated !

My second attempt with a proper language description works:

#@admin
#@language en-gb
rah_wrach_frontpage_label => FRONT
rah_wrach_frontpage_tooltip => Published on the frontpage
rah_wrach_rss_label => RSS
rah_wrach_rss_tooltip => Included in RSS feeds
rah_wrach => Wrach
rah_wrach_show_sections => Display the following sections (comma-separated)
rah_wrach_hide_section_input => Hide the section input?

Maybe it’s a little bit strange?


Patrick.

Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.

Offline

Board footer

Powered by FluxBB