Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
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
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
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
Pages: 1