For new software, the awareness machine is cranked even harder. Videos. Social media campaigns. Billboards. Search Ads. Embedded video ads. The works.
Twenty years ago, the landscape was very different. There was advertising, sure, but nowhere near the scale of today. And, perhaps to celebrate the fact that Dean Allen’s newly created CMS was so small, nimble, lightweight, yet powerful – or perhaps because its creator was an eccentric genius – the fanfare surrounding the official birth of Textpattern was this:
Public Gamma 1.10 is up. I’m going to bed.
That was it; the extent of the marketing campaign. Nothing more. Nothing less. A factual statement and an indicator that the road to reach it from the numerous alpha and beta releases throughout 2001 until its naming in 2003 and public release in 2004 had been arduous, yet worth it.
Since then, Textpattern has gone from strength to strength, and still we’re innovating. True to the form of Dean’s creation, we might not release a new version every few weeks like other CMSs, and we might not make as big a deal out of them. But each release is carefully crafted, built and tested for compatibility and performance. Even upgrades from fifteen-year-old versions go smoothly.
Pages are served lightning fast. Content and its presentation are still generally separated to make long-term maintenance and design refreshes a breeze. Alongside this, we have some truly unique and world-beating features to aid iterative site changes. And the clean and snappy administration interface still remains accessible to users of assistive technology – something we’re expanding with each successive version.
As Textpattern enters its twenty-first year and we’re gearing up for the 4.9.0 release – slated to be the last of the 4.x series – we all wish it a bright future and hope it continues to be the content management system of choice for enthusiasts, developers and lovers of the written word that it’s always been.
Happy Birthday, Textpattern.
]]>From v4.7.0, reliance on that resource was designed out of Textpattern completely: language Textpacks (i.e. the translated text for supported languages) ship with Textpattern in its lang
directory. This has a number of important ramifications:
Thus, the strings you have in your database when you download and install Textpattern are the only ones you’ll get. You may think that’s a bad thing… a regression in functionality. Well, yes and no. You’ll still be able to get language pack updates between releases if you wish, but there’s no real need to do so, since all the strings Textpattern needs are shipped with each release.
If you do wish to update the language pack (for example, to bring down new or altered strings in response to a change or bug fix), you perform a three-step process:
lang
directoryFar from being a regression, this gives you greater control over the process than relying on the server telling you that updates have been made; updates that may have not applied to the version you have installed, or that may adversely affect the user experience.
Bundling the strings directly in core does mean that the overall size of the uncompressed Textpattern distribution has increased significantly – almost double – because all languages are present instead of just en-gb
. But the benefit of having all languages instantly available to install without any external server involvement outweighs the file size bump.
We continue to prune legacy strings. To put this in context, a typical lang table in Textpattern 4.6.2 had over 1300 core strings per language. Each string takes up a database row. Install a couple of additional well-represented languages and you’re looking at almost 4000 rows. That’s a lot of data. Since many of the strings simply weren’t necessary – merely there to support legacy versions – we’ve removed a few hundred strings per language from the out-of-the-box installation.
We haven’t yet taken the step of forcibly removing old strings from your database on upgrade because we don’t wish to risk deleting plugin strings by mistake, but new installations (and those people that delete and reinstall an entire language pack) will benefit from a leaner database. It’s a step that’s well worth taking if you know there aren’t any custom strings you wish to keep.
Taken in isolation, the above changes might seem unnecessary or a backwards step, but they’re part of a broader spectrum of alterations.
One major change from 4.7.0 onward is that we no longer use en-gb
as the default language. It’s now en
, or Oxford English, which is an international standard mashup of en-gb
and en-us
.
We have also opted for reducing how opinionated our languages are. So instead of the full language designators such as fr-fr
or ja-jp
, we have used the simpler language identifier where appropriate (fr
, ja
, etc). Plugins and code that use the old identifiers will be seamlessly converted to the new ones, though we encourage plugin authors to start using the new designators in code going forward.
To make things simpler for Textpack management, language designators may be listed in a pack. So if strings in your plugin can apply equally to a bunch of languages, you can define them once and benefit from the same strings being loaded for any of the given languages:
#@owner your-name-or-plugin
#@language en, en-gb, en-us
#@your-plugin-name
english_key1 => value1
english_key2 => value2
...
#@language fr
french_key1 => value1
french_key2 => value2
The number of languages continues to increase, taking our official supported tally to 54 as of this writing, including the latest addition to the flock: Fulah. Our translators work behind the scenes on Textpattern translations at CrowdIn, and we welcome contributions from anyone for our current languages or new ones. Please get involved if you can to help the majority of these bar charts near 100%. Every translation helps countless administrators and users around the world.
As of this article, Textattern supports a single front-end website language, chosen from any of those installed. There are techniques you can employ via plugins or code snippets to deliver content in multiple languages but it’s not a core feature yet. We’re actively working towards true multi-lingual content.
On the back-end, however, authors and administrators can select the language in which to display the admin panels. Each user can choose any language that suits them, selected from those that an administrator has installed. Administrators also get to see how many authors are using each language via a counter alongside the language designator. This is a handy visual aid if you wish to remove a language, as you can gauge its reach among your user base.
Two additional features are:
In an effort to reduce the memory load on each page, all language strings are represented according to their events. That means we have strings that only appear on the Preferences panel in a [prefs]
group. Strings that only appear on the Files panel are in a [files]
group, and so on. The group is the name of the panel given in the URL after ?event=
.
On any given panel, only the strings that are required for that panel are loaded, plus the [common]
ones (see below for an overview). This system extends to plugins, so if you want strings to appear on your own plugin panel, make sure they are assigned to a group that matches [abc_your_plugin_event]
.
There are several special groups of string:
[admin-side]
strings are loaded on every admin-side panel. So anything that appears in the menu (such as your plugin panel’s name), header or footer goes here.[public]
strings are loaded only on the public website.[common]
strings are loaded on both the public website and every admin-side panel.So if your plugin is rendering abc_plugin_string
instead of the correct translation, check it’s in the correct group. The smd_babel plugin is a handy back-end tool for checking, altering and applying language translations to any language for any string.
It may seem tempting to stuff all your strings in [common]
for simplicity, but please don’t do this as it’ll increase the memory footprint of the public site too, and every admin-side panel. Instead, if you need access to strings from another group that’s not one of the special groups mentioned above, employ code like this:
// Fetch a reference to the language class if you don't already have one.
$langObject = \Txp::get('\Textpattern\L10n\Lang');
// Extract strings from the given groups in an installed pack.
$strings = $langObject->extract('<langDesignator>', array('article', 'image', 'prefs', ...));
// Set the internal strings to use them.
// true = append to what's already loaded, false = replace entirely.
$langObject->setPack($strings, true);
Textpacks are handled seamlessly in plugins. Previously, Textpacks were only installed for the current language when a plugin was installed. If you subsequently installed a different language—even if it was represented in the plugin—tough.
When you install plugins in Textpattern 4.7.0+, you are shown its language pack(s) at the Plugin Preview step, and all these packs are stored along with the plugin itself in the database. This means that if you have French and English languages available in Textpattern at plugin installation time, you get the plugin’s French and English strings installed. But if you later install German and the plugin had a bundled German Textpack, it will be installed as well at that time.
This is a massive help for plugin authors as you can embed all relevant strings in any languages in your plugins and have Textpattern automatically install them for any language. If an administrator removes a language and reinstalls it, the plugin strings come along for the ride and are automatically reinstalled.
Further, if a language is missing from a plugin Textpack, or only partially translated, the strings from the default language will be used to fill the gaps. This is known as your fallback language and it’s set by default to en
. It can be changed in your config.php
by setting the constant TEXTPATTERN_DEFAULT_LANG
but it’s probably not advisable unless you know what you’re doing: you should certainly choose one that is well-represented, preferably one that has 100% of its strings translated or you’ll get untranslated strings in your interface.
The above language segregation means it is imperative that you designate the #@language
in your Textpacks for correct language assignment. You can no longer rely on the ‘default’ (current) language being the first one in the list if it doesn’t have a designator. Language strings in a pack without one or more designators will always be assigned to the default fallback language (en
in most cases), which may not be desired.
This also applies to plugins loaded from the plugin cache directory. Any strings for the currently-used admin-side language of the user, or the language for the public site, will be loaded on-the-fly from the plugin file.
As we progressively add features, we’re working towards bringing a full multi-lingual experience to Textpattern. We’ve already made iterative steps in that direction by:
As it stands, a combination of plugin code and a little clever form processing can get you most of the way. There are a few wrinkles around the edges, such as implementing a mechanism for natively tying content that differs only by language, and syndicating it. That’s all less than optimal right now and requires planned database table changes and a tweaked UI workflow to tie everything together.
But with some ingenuity, it’s possible to deliver a multi-lingual front-end experience in the latest version of Textpattern; at least for two or three languages before it becomes unwieldy to manage. There have been various discussions around multi-linguality including one on language handling at the tag level, and a full proposal document (Google Doc).
As with any proposal, community members form a key part of the process. So if anyone has any questions, comments or ideas, please raise them here, on the forum or in the proposal document (whichever medium is most appropriate) so it can be considered. We are especially interested in the views of people who routinely make (or who have tried to make) multi-lingual content websites in Textpattern.
Being able to adapt the interface and content management goals for the most flexibility using suitable conventions to simplify the process is the aim. Thank you in advance for any thoughts you may have.
]]>The mission was clear: turn Textpattern supporter donations into a significantly greater amount by way of a $75,000 match funding piggy bank provided by Sustain OSS, GitCoin, Synthetix and others. The equation used to top-up donations favoured smaller donation amounts; $5 in the tip jar turned into nearly $50, a massive uplift from the original pledge.
After 14 days of jar-rattling, attention-grabbing appeals for a few coins – and ultimately the generosity of those donors plus the piggy bank – over $3,500 was raised and contributed to Textpattern on Open Collective.
We are immensely grateful, humbled and appreciative of this incredible amount. We operate a transparent budget for our project, the details of which can be found at the Open Collective above, and you can be assured that we will extract every last iota of value from your contributions. We are continuing to further improve Textpattern and make it as good as it can be, and these funds will help us hugely.
Thank you FundOSS, your pilot program funding partners, and each of the 52 Textpattern supporters. You are amazing.
]]>FundOSS have raised a $75,000 matching fund. Support us and they’ll back you up by multiplying your kind donation based on how much support we receive before the deadline on June 24, 2021. If you’ve ever considered supporting us financially then today’s the day to put that thought in action. The match funding pool will be allocated primarily on the frequency rather than the volume of support for Textpattern, so please consider donating an amount – however small – before June 24th so our project, users and community can all benefit from this incredible opportunity.
Details of how to donate can be found on the Textpattern FundOSS page. We’ve already had some very generous sponsors and the devs have chipped in too, so thank you very much to everyone who has contributed so far. Any and all noise you can make on your social and web channels to support this drive will be a huge win for the project. Being in such a small pool of projects in a campaign like this is a fantastic opportunity and will provide valuable exposure for our CMS.
At the time of writing, a $5 donation attracts an estimated $43 match from FundOSS – over 7 times the original pledge value. Matching for larger donations is also currently available, but the pilot piggy bank is finite so time is of the essence.
The multipliers are changing as more people get involved. Over $16,000 of the fund has been allotted already in just the first day of the campaign, so please don’t delay. Even a small contribution will be amplified and make a tangible difference to the way we can promote, support and continue to evolve Textpattern to help you build engaging websites for your clients and communities.
Thank you for your interest in Textpattern, and for your considerations in supporting us.
]]>Up until that point, I had a hard-coded website that I’d iterated over time in various languages available at the time: bits of HTML, server-side includes, CGI scripting, Tcl, and so forth. I’d never really heard of Content Management Systems but knew I wanted something more dynamic so I could publish content and inject it into templates, in a better way than I’d been doing.
So I started hunting the ol’ internet and discovered this expanding world of the CMS; a concept that promised to separate content from display and revolutionize the way I managed my site.
Mind blown.
With the giddy playfulness of a kitten chasing a length of string soaked in catnip, I clicked to open the first piece of software in the list – the most popular one called WordPress. Downloaded it, installed it on my web host, logged in.
And my dreams careened into a wall.
In WordPress, I scratched my head a bit. Clicked and poked around the confusing and badly-laid-out back-end system. Waited. And waited. And waited for the interface to catch up with my clicks. Changed a few things (eventually) and began to see how the content was stored and how it was represented in the templates. Not so bad, I guess. Made some sort of sense.
Ever inquisitive, my next thought was: okay, so let’s change this layout so the links are over there, the categories here, the title is in a different font, the menu left aligned and so on. Perfectly reasonable things, I thought.
Could I do that?
No. It didn’t seem possible. Surely that couldn’t be right? My understanding from reading up on this brave new world of publishing was that the whole point of a CMS was to allow people to easily change how their content’s laid out.
I dug some more. Found the Themes area of the system, packed with a tonne of pre-made layouts. Scrolling through the list, I found one that looked close to what I wanted and clicked to install it. Refreshed the front-end page. Boooooom! Error messages abound. Content smashed up, stuff smeared down one edge of the screen. Images cut off. It was a mess.
I tried another theme. Similar results: errors in different places, content still broken. Eventually, I found one that didn’t break as much, but it was a far cry from the look I wanted. I hunted for things to change. The header and footer were separate, which was great. I could move a few things, tweak colours using sliders in the interface, but that only seemed to affect one section of the site.
If I changed the ‘global’ settings to apply a colour site-wide, it worked, but overall it began to dawn on me that I could only change what the theme designer had allowed me to alter. Font size and colour, but not placement. Position of the blocks on the page, but not the type of bullet point used in lists. That kind of thing.
I searched the web and found plenty of ‘advanced’ tutorials on how to change such rudimentary (to me) things in themes by first making a copy of it and then overwriting stuff. Seemed I had to understand something called “The Loop” and be able to program PHP, neither of which I cared enough to learn, simply to make one tiny change to the way the page rendered.
With a crushed spirit, I uninstalled WordPress and tried Drupal. Different animal, similar issues. Joomla: great if I wanted to learn to crawl before I could eat, but I was hungry. Typo/Blogger: purr-leazze!
I spent days, weeks, installing and trying and uninstalling software that promised so much and delivered so little. Too slow, too convoluted, too rigid. I became despondent, rapidly coming to the conclusion that maybe my home-grown solution was best and that there was no such thing as a CMS in which I could have a good starting point and then tweak things to my liking. To be able to dive in, change one little line in a template and have the entire site alter and flow my content beautifully.
One evening, out of sheer desperation, I clicked a link hitherto buried in the search results. Some guy called Jon Hicks had written a blog post. Had mentioned this little CMS called Textpattern and how he was using it. I’d never heard of it, but it sounded alright. What did I have to lose, besides another iteration of install-try-scream-uninstall?
I downloaded it, read the README. Installed it. And fell in love.
The interface was yellow. Very basic. The two-tier menu system was clunky, but that immediate separation of content and layout was beautifully apparent. And it was fast. No waiting for three metric tonnes of JavaScript to render the administration panels. If I clicked into the Content area, I was right there: able to Just Write. To type new articles, add links, upload images, attach them to said articles and have them show up immediately.
Venturing into the Presentation area, I could see every page template assigned to every section – some shared to cut the workload. It was mostly HTML, smattered with tags beginning <txp:...>
that seemed to act as placeholders for dynamic content read from the database: <txp:title />
to show the article title, <txp:body />
to show the article body text, <txp:section_list />
to create the menu from the sections defined in the back-end, and conditional tags like <txp:if_article_list>
to show something different based on how the visitor navigated the site.
It was all very logical, which appealed to my sensibilities. Plus, the CSS (stylesheet) was editable directly so I could change anything and everything I liked.
There were these confusingly-named things called Forms that seemed to act like reusable snippets of templates. I wasn’t quite sure how they worked, but if I made a change to one, it affected a whole swathe of stuff on the website, which meant I could tinker to my heart’s content and learn how everything fit together. I played with attributes on tags, and stuff changed exactly how I expected on the website.
It was a dream. Finally, my inner kitten had the string it craved.
I signed up to the Textpattern forum that same day. January 29th 2006. Made a few tentative posts over the next few days, mainly asking stupid questions. Dug around. Installed a few plugins. Some did what I wanted, some didn’t.
The templates and tags are flexible and customizable, but I could immediately see that to help myself and the community of designers and coders, nirvana was being able to find gaps in Textpattern and fill them with plugins. To make code that would ordinarily require a bunch of core tags to achieve, and to package that up in a single, flexible tag that could enhance things. Make it simpler still.
The only thing that stood in my way was not knowing PHP. But I now had the impetus to learn it. I wanted random text on my website drawn from a pool of sentences of my choosing. I found a plugin (dru_random_text, fact fans) that almost did what I wanted, cloned it and used that to learn the programming language. Wrote one, two, three… sixty plugins (most of which have now thankfully become obsolete due to gradual improvements in core functionality).
From those shaky beginnings, in 2009 I was blessed with being invited to the core development team and I’ve been there ever since, thoroughly enjoying working with a skilled team of designers, coders, writers, admins, testers, enthusiasts, and like-minded tinkerers, all striving to make this wonderful system the best it can be.
Throughout my time with the CMS, the cornerstone to the project has been the warmth and breadth of knowledge in the forum. At the risk of schmaltz, it’s my happy place where I learn new stuff about the worlds of design and content and tips and tricks and coding and friendship. And, most importantly for me, it’s where I can share what I’ve learned and pass it on.
Over the years I have had the good fortune to interact – virtually via video or the forum – with such a talented pool of individuals, and have met many members past and present in person. Examples include the amazing people behind these forum handles: amoredecosmos, destry, gaekwad, graeme, jakob, jsoo, lazlo, mistersugar, netcarver, philwareham, and zero. I’m sure there are more, and apologies if I’ve missed anyone.
Today marks my ten thousandth post in the forum. Yes, 10 000; that number still barely seems real. Yet there are thousands upon thousands of posts alongside mine containing a wealth of information on all things Textpattern and beyond, and with the help of people in the community, we’re gradually curating and distilling the best of it into sharper documentation and tips to make it more readily available and digestible for the user base at large.
Thousands of websites breathe Textpattern and help people do business, or showcase talent, or convey thoughts to the world through blogs and news channels. There have been many changes in the software over the years and it continues to evolve. The project’s founder, Dean Allen, passed away. Community members come and go; many come back again. And yet, amid the natural ebb and flow of an open-source project – the core principles of power, performance, elegance, flexibility, community and, above all, the ability to Just Write still beat at the heart of the place I’ve called home for fifteen years.
So a special thank you goes out to Jon Hicks for evangelizing the project in the early days, allowing me to discover it. And thank you to everyone involved in Textpattern who has helped – and continues to help – shape it. Your patience and dedication shine through its fabric. I love being part of this project, and look forward to seeing you – and many new faces – between now and my twenty-thousandth post.
]]>Please note: the development path for Textpattern 4.9 is at an early stage. There will be additional changes to those outlined below. We aim to keep you updated on new features, functionality and any notable differences as work on Textpattern continues.
Textpattern 4.9’s minimum system requirements will increase to PHP 5.6 or newer, a change to the current minimum of PHP 5.5 for Textpattern 4.8. Although Textpattern 4.9 will run on PHP 5.6, it is notably faster and more secure on a newer, supported version of PHP.
Vendor support for the legacy PHP 5.6 series reached End Of Life in 2018. Any security issues arising will no longer be addressed by The PHP Group. An important part of the Textpattern development cycle includes updating and removing code for old, unsupported PHP versions. This has a benefit of further improving performance for sites running on newer PHP.
Team Textpattern recommends a supported version of PHP as a foundation for your Textpattern sites. At the time of writing, PHP 7.3 and 7.4 are actively supported and best for performance and security.
We are also taking steps to ensure Textpattern will run on PHP 8, expected to be released in late 2020. We are following the PHP development process closely and we will make any necessary changes to Textpattern, so you can be assured of full support for PHP 8 in due course.
Internet Explorer browser support is being removed in Textpattern 4.9. Microsoft have replaced Internet Explorer 11 with Edge as their flagship browser, with a recommendation for Internet Explorer 11 to be used only for legacy websites.
Textpattern is developed and maintained to balance the need for some backwards compatibility, without adversely affecting the experience for the vast majority of administrators and contributors using modern browsers. Textpattern 4.8 includes a variety of workarounds for Internet Explorer and its well-known limitations and quirks. Textpattern 4.9 will remove these workarounds, further optimising the experience for most people using modern browsers.
Team Textpattern recommends your site visitors, administrators and contributors use a supported browser from a well-known, trusted vendor.
If your organization actively uses Internet Explorer, perhaps in conjunction with Textpattern as an intranet platform, we advise you not to upgrade to Textpattern 4.9.
We are making some changes in Textpattern 4.9 that will affect a minority of Textpattern sites using old PHP and old Internet Explorer. New PHP is much faster, safer, and actively supported. The removal of Internet Explorer support will also improve performance.
We are keen to share our Textpattern 4.9 intentions with you. We aim to publish more articles with additional information as discussions happen and plans are confirmed so you can prepare for the arrival of Textpattern 4.9 appropriately.
]]>The version numbers attached to Textpattern releases relate to their chronological order, and they loosely follow the semantic versioning format. I say ‘loosely’ with a caveat: the earliest days of Textpattern development were driven by project founder Dean Allen, and pre-1.0 releases had version identifiers including ‘g117a’ and ‘1.0rc3’. When I refer to ‘pre-1.0 releases’, this is somewhat misleading since a public release of Textpattern 1.0 didn’t materialise. Dean released what was considered a stable, production-ready Textpattern 4.0.0 for general use.
Textpattern version 4.0.1 arrived soon after, with improvements and a few bug fixes thanks to the effect of more people with eyeballs and keyboards becoming involved. Textpattern versions 4.0.2 – 4.0.8 followed over the years with further fixes and enhancements. Textpattern 4.1.0, codenamed “crockery”, was intended to become the next big step up for the platform but – despite a lot of code being worked into a parallel branch – the feature set and associated changes proved too ambitious for a single release. Textpattern 4.1.0 never materialised and was ultimately skipped. The code was either jettisoned or kept; for the latter, changes were gradually merged into subsequent versions 4.2.0, 4.3.0 and 4.4.0 at a more sustainable pace.
In semantic versioning parlance, release numbers follow a ‘major dot minor dot patch’ format. Most Textpattern releases are patch releases, essentially fixing (patching) bugs or issues. New or enhanced functionality is typically added in a minor release, and a major release is usually attached to significant code overhaul that might have backwards compatibility issues. Looking at the Textpattern release notes, it’s evident that minor releases often include numerous enhancements and improvements over the previous minor release, and patch releases sometimes augment existing functionality as a result of wider feedback from the Textpattern user community.
Textpattern has one major release (Textpattern 4.0.0, released in 2004), 6 minor releases and about 20 patch releases on its track record, if applying the semantic versioning model rigorously. Semantic versioning tells us that a backwards-incompatible change is a trigger for a major release. In real-world, day-to-day Textpattern development, it’s not always clear when a minor release gathers enough change to justify a major release, as is evident with one major release about 15 years ago. Whether this is a side-effect of crockery’s bumpy ride or other factors – such as Textpattern’s well-known efforts to make upgrades as painless as possible – is open to interpretation, as is the extent to which our CMS adheres to semantic versioning rules. The next version of Textpattern might be 4.8, or 5.0.
The most recent roadmap published here (see Textpattern Portishead meet 2015) focused on the then-upcoming release of 4.6, with a nod toward plans for future versions. The roadmap was largely adhered to for the 4.6 release cycle, and a lot of the changes for 4.7 were also on target. Textpattern’s developer community uses GitHub’s issue milestone feature to maintain a living Textpattern roadmap. Issues represent upcoming changes to Textpattern, and the associated milestone is a marker for when it’s planned to happen. Software roadmaps and milestones evolve with time, such is their nature, and the consensus is that with the release of version 4.7.3, the Textpattern 4.7 cycle is complete. With that in mind, Team Textpattern will discuss, plan and work on the next non-patch release.
In no particular order of priority, and without prejudice, here’s a selection of headline changes currently on the Textpattern Next Non-Patch Version Roadmap (and yes, we might revisit that name):
Great care is taken to ensure the Textpattern upgrade process goes smoothly, and that administrators or users don’t get nasty surprises. It’s likely that future developments in Textpattern will introduce one or more backwards compatibility issues which may not be easily mitigated with code or documentation. As work on the upcoming Textpattern release series continues, we’ll reach a point where we know whether it will be released as Textpattern 4.8 or Textpattern 5.0. In either case, you will find explanatory release notes to help you determine if your Textpattern instances will be affected by any of the changes made.
Textpattern continues to evolve and adapt. Engaged users with critical, real-world feedback are an important part of open source project development, and these contributions aid with bug swatting and overall enhancements. Textpattern core has no code for gathering usage metrics, and has no spyware or similar undesirable software to ‘phone home’. As such, we value input from our global user base to help guide development based on need and available resources.
And now, over to you. What is most interesting or relevant to you on the headline changes listed above? What can you offer to help us meet our next release goals? Whether you’re a seasoned Textpattern administrator, an active user, or coming to Textpattern with fresh eyes, we’d love to hear from you. Please use this thread on the Textpattern forum and share your viewpoint. When we have more firm plans and news on the above items, we will publish articles on each and invite comment. In the meantime, keep an eye on the various feature branches in the official repository for early access to these new features as they are developed. Please feel free to jump in with code Pull Requests or for raising issues against a particular feature branch to guide the development process.
]]>For newcomers, after the power of tags has been grasped vs having to learn to code first, most people never look back. And rightly so: it’s a phenomenally powerful platform. But Textpattern’s greatest strength—a clean palette upon which to build—has traditionally kept people who are not already designers away. It’s never been a truly ‘plug & play’ experience.
That’s no longer the case from Textpattern CMS 4.7.0 onwards. But before getting into what Themes are, here’s a brief bit of background into our approach and how it compares to other CMS tools.
One of the main draws of a tool such as WordPress has always been about taking something that someone else has done and putting your content inside it, then using that to build your site upon. If you decide you don’t like the look, swap it out for one you do like. There are endless templates—free and paid—that can be used, with varying degrees of success depending on the template author.
Textpattern has always shied away from this. Partly this is due to its architecture; the very thing that makes it simple and elegant—a Section containing Articles has a Page and a Stylesheet associated with it—makes it easy to iterate or swap out page furniture on a Section-by-Section basis, but it’s very difficult to try something new alongside.
Most of the arguments that have raged for over a decade against our lack of themes tend to come back to a few central concepts:
default
and comments
Forms?Prior attempts at tackling this system fell by the wayside because they tried to take it all into account, and Textpattern is simply not architecturally geared up for this. So what’s changed? Why have we now succeeded where we once failed?
Simply put, we took a step back. Spurred on by Bert Garcia, one of the major proponents of themes, and author of the ‘hcg_themes’ plugin that has been the mainstay of many people’s sites over the years, we took a look at what a Theme actually is and, more importantly, what it isn’t.
Our current definition of a Theme is:
Nothing more, nothing less. No plugins, no Sections, no content, no preferences. Just the bare template furniture. In future, we plan to expand this and introduce such additional items. For the impatient, we’ve built some fantastic goodies under the hood for plugin authors to play with that will allow fully-fledged theme plugins to be created with all of the above features. More on that later.
So if a Theme is nothing more than a few bits of scaffolding, why the fanfare? Why the big deal?
The main problem to date has been that if you want to migrate a site to a new layout or design, you have two choices:
Our approach in Textpattern CMS 4.7.0 has been to lean towards the former while removing as many of the risks and hacks associated with it. Given the choice, most people who want to migrate to a new site ‘skin’ would prefer to do it in a safe, parallel area without having to faff with database resynchronisation or setting up entirely new (sub)domains and site environments.
With that in mind, upon upgrade to the above mentioned version, you’ll notice, well, very little difference save for the introduction of a new Presentation panel labelled, unsurprisingly, Themes. First-time installers will be given the choice of the default theme or an ‘empty’ theme (or at least as empty as Textpattern knows how!) during the setup process.
Visiting the Themes panel will show you one theme (default) and that’s your current site. Not ours. Not anyone else’s. It’s your current site. If you’re happy with that, great. Call it Donald Swain if you like, it’s up to you. Nothing else will change on the Pages, Forms and Styles panels, it’s business as usual.
The fun starts if you create a new Theme or duplicate your existing one. A new selector then appears above the asset lists on the Pages, Forms and Styles panels, allowing you to switch Theme. As soon as you do that, you are editing all assets for the chosen Theme and the one you are working on is remembered from panel to panel.
One important feature is that, all the while you are editing assets in a Theme that is not in use by your site, nothing on your current public-facing site is affected. You can tinker away on your new design and change Pages, Forms and Styles to your heart’s content, directly in your live Textpattern installation, without any ill effect on your existing site. As long as you don’t start altering plugins or changing prefs that affect the entire site, nobody is any wiser.
It’d be no good working away in the dark, so Textpattern now has one more trick up its digital sleeve. If you are editing any Theme, you—and only you—can preview what that Theme looks like by viewing the public site as normal. Whichever Theme you are editing temporarily overrides the real Theme in use across the entire site. Regular users who are not logged into the admin side continue to see the site as it was.
The huge productivity benefit here is that all your content is still in place. No need to mess with synchronising data to other installations to get the latest article content; you get to see what your site will ultimately look like, directly on the live installation. Even better, you can give clients a preview too. You could make a series of parallel Themes and grant your client appropriate user privileges. They can then switch between Themes from the admin side and refresh the public site to see what each looks like in-situ. Very handy.
So far so good. You can copy, edit, and preview your Themes with live data in an isolated environment that has no effect on your user base. When the moment arrives that you want to showcase the new design to the world at large, it’s as simple as visiting the Sections panel. You can either click a Section as normal to edit it, select a Theme, Page and Stylesheet for that section and hit Save. It’s then live. Or use the multi-edit tool to apply a Theme, Page and Stylesheet to all the selected Sections.
This approach has one other exceptional benefit: you don’t need to apply the Theme to your entire site. Want the blog to look different? Just assign a different Theme to that Section. Want your gallery showcase to be a bit snazzier? Use a different Theme just for the affected Section(s). Textpattern will show you which Theme is in use for each Section and show you the number of assets in use by each. It’s like using a bunch of Pages for different parts of your site, but they’re entirely independent of one another.
You won’t be able to accidentally delete a Theme that’s in use, so no fears there. On the Sections panel, if you click the number representing the assets of that type, it’ll transport you straight to the corresponding Pages, Forms or Styles panel and switch you to the assigned Theme so you can edit the presentational aspects of it immediately.
That’s not all. The final piece of great news is that you can package up any Theme and export it to the file system. Each Page, Form and Stylesheet in the Theme occupies its own space under the themes
directory. This has two benefits:
themes
directory in its entirety, then visit the Themes panel to import it. Whether that’s your own creation or someone else’s is immaterial.Anyone who’s used rah_flat or oui_flat will instantly see how useful this is to have in core. And, in fact, most of the Theme import/export code has been written by Nicolas Morand of oui_flat fame so you can be sure it’s based on the considerable experience gained through maintaining his excellent plugin.
The main differences are that we’ve deliberately taken two features of the plugin out. Firstly, the ability to import preferences is not there. Secondly, the auto-synchronisation-when-Live aspect is removed: if you want to import a theme into Textpattern, you must manually do so from the Themes panel.
This workflow aids clarity and minimises the chance of overwriting your templates. Textpattern does not serve its Themes from the filesystem; they continue to be served from the database only. The ability to export and import is merely a convenience feature for version control, backup or sharing of Theme content. The furthest Textpattern goes is offering you the option to clean out any unused assets prior to import/export, which will remove all assets and use a completely fresh set instead of merging the content.
While the ability to manage Themes and their assets is pretty cool, on its own these features would be very limiting. So we’ve let plugins not only have access to the full set of import/export actions, enabling plugin authors to augment the concept of Theme building, but also bundled some excellent additions in the background.
In our vendors
namespace, plugin authors will find a virtually complete system for import of XML files. You can define XML files for Article content, Categories, Sections, Pages, Forms, Styles, Preferences, Links, Comments, even database table definitions. Methods allow content be pulled into the database from flat files. In fact, core now uses this system during setup and upgrade.
This library enables plugins to natively and easily handle content import. Should anybody wish to do so, it’s now possible to write a plugin that replaces the entire ‘import data from another CMS’ that was ditched in the last version. And, in fact, make it a hundred times better than the creaking importer we sliced out of core.
The only reason we’re not shouting about this library just yet is that the work isn’t complete. We need to possibly figure out file and image imports, and write a companion export library, unifying all the Theme code so it uses the import/export library instead of its own. We’re looking into that for the next version so keep your ear to the ground.
For now, our concept of a Theme will remain strictly Pages, Forms and Styles. For future, who knows, we might extend the concept to include prefs and plugins or Sections, although these all bring their own challenges and require a ‘wizard’ approach, since importing such content has the potential to overwrite existing data.
We intend to consider—and please note, this is only a tentative idea that may never see the light of day—the following:
We’ll likely still use the themes
directory but choosing to export would ask you which components you wish to bundle up, and choosing to import would ask you which parts you wish to bring in and potentially overwrite.
All in all, we’re really excited to finally bring the ability to manage Themes to Textpattern. We hope it’s a useful feature that spurs a load of shared Themes—we will endeavour to host anything people create so the community can benefit and expand—and allows you to maintain and push your existing sites forward with less hassle than now. Anyone who can’t wait for v4.7.0 to hit the shelves can either download the latest snapshot from GitHub or give the development version of the demo a whirl.
]]>A volley of forum posts between Stef and Phil Wareham got the ball rolling, and before long a plan took shape. The 2011 Textpattern event went down in Bristol, so our 2015 gathering continued that tradition. The venue was finalized, hotels were booked, and when the day came three men (and zero whiteboards) gathered in Portishead, near Bristol, UK to talk Textpattern.
We found a table in a local Wi-Fi-enabled tavern and jabbered for hours, with lots of hand-waving, eye-rolling, and wiping froth from mouth. We made notes, formed plans, and scoped out a roadmap for upcoming Textpattern CMS releases, including what features would make version 4.6.0. It was an amazing, tiring, and inspiring day. The value of having a core Textpattern designer and developer in the same room was huge.
The 4.6.0 roadmap—yes, that ‘R’ word from which Textpattern has traditionally shied away—is being formalized into GitHub milestones to aid tracking and progress. The milestones have been fine-tuned against the 4.6 development process. So here are the remaining items, to build upon the immense amount of things that have already gone into 4.6.
Timescales are difficult to pin down and commit to, so I’ll sidestep the inevitable question of “When is Textpattern 4.6.0 coming out?”. I can say it’s nearing completion and a collective push towards achieving the outstanding items on the shopping list above will facilitate the process. The current focus is on getting the pieces in place to release 4.6.0 in early 2016. There will be one or more beta releases, one or more release candidates, and a full release of 4.6.0 with a bunch of new features and improvements.
Following the Textpattern 4.6.0 release, work will focus on migrating Textpattern website resources to textpattern.io, away from textpattern.com and other Textpattern domains owned and maintained by external entities and third parties. Textpattern documentation is already being revised and ported from textpattern.net to textpattern.io, with many considerable improvements.
The numerous conversations over the day also touched on features that are in-progress but won’t be ready for the upcoming 4.6.0 release, primarily to balance the need for copious testing and to prevent any more feature creep delays. The 3-digit numbering approach follows the semantic versioning scheme of major.minor.patch releases, and while it’s technically possible to squeeze more minor/patch changes into the 4.6.0 release, we agreed to work on additional features and improvements after 4.6.0 is available. Immediate focus is squarely aimed at getting 4.6.0 released, with interim releases afterwards at shorter intervals than we traditionally achieve.
To that end, some high-level plans were sketched.
Again, by the nature of software roadmaps, this will change.
Looking further into the crystal ball, some additional intentions were noted for 4.8.0 and 4.9.0—but you know crystal balls, they can be cloudy.
If you have skills that will benefit Textpattern development, for 4.6.0 and beyond, we’d love to hear from you. It doesn’t matter if you’re a coder, a tester, a writer, a translator, a hacker, a helper or any combination of the above—the more momentum we can muster, the better Textpattern will become!
]]>But first you need an explanation about why we (as a community) have come to this juncture with the magazine. It will concern those who have been in the Textpattern community since at least 2011, when the magazine was re-launched. Newer community arrivals may appreciate the lessons learned.
To be sure, I’m not exiting the role of editor-in-chief because I didn’t enjoy it, or because I got burnt out from the time (plenty of it) I invested into it. Nor is it because I didn’t believe the new magazine initiative had potential to bring visibility to the Textpattern project—it certainly did. After just two issues, for example, we had the attention of this writer at Smashing Magazine, who advocated to Smashing’s huge readership to keep an eye on our publication:
[T]his publication aims at providing the best publishing system conceived, discusses topics with the community, and features experts in the field. [It] also features topics that aren’t directly related to Textpattern, so even if you aren’t using the CMS, you might want to check the magazine as well.
That person clearly understood my vision regarding TXP Magazine’s purpose, and the article is proof that audience reach was happening. That made me happy. Despite not attaining our goals, I’m proud of what our “media team” accomplished. When I look at TXP Magazine now, sitting idle for two years, I’m still impressed by what I see and read. The presentation alone is better than that of most websites launched today. It’s not a cookie-cut repeat of the trendy pattern du jour, then or now. It’s a unique representation of exactly what we set out to create, right down to the advertisement art by Stephan Simonis—all-in-all a classy and professional reading experience. I might be biased.
No, the reason I’m exiting is due to something entirely different, something out of my control. It’s because despite my hope and ideas for the publication, they were misplaced in such a small community. My role as magazine editor was unnecessary, evident by the few article contributions I could get the Textpattern community to make.
I don’t blame you one bit. As everyone in the writing business will tell you, writing is hard. Good writing is harder. Having the patience, courage, and understanding to let someone edit your copy is harder still, especially if English isn’t your native language. I get it. You don’t want to go down that difficult road. But as the trite saying goes, therein lies the rub. There’s nothing to read and talk about if nobody is writing.
Maybe you’re wondering why I didn’t write more myself. After all, I am/was the editor, right? I could have written more. I’m full of ideas and opinion. I could have filled in all the columns of each issue on my own sweet time. But not only would that bore the crap out of you, it’s not the editor’s role to do all the writing. If I did all the writing, it wouldn’t be a magazine—nor a community effort—it would be a personal a blog. Destry’s Textpattern Diary.
The editor-in-chief of a magazine has many responsibilities, all geared to making sure the business of publishing happens. Wikipedia summarizes it nicely: “An editor-in-chief is a publication’s editorial leader, having final responsibility for all operations and policies.” That includes decisions with presentation and advertising as they pertain to the strategy of the publication. I lost some of that decisional power along the way (the first sign of trouble), which only compounded the contributions issue. Presentation and advertising mean absolutely nothing if magazine content is not published regularly.
Editors often write dedicated Editor’s columns too, which I did with TXP Magazine each issue. My quota was filled. It was a column I partly used to try and rally the troops—you—to no avail. But I pressed beyond the call of duty and wrote a number of other column articles too with the hope of getting the balls rolling, your ball bearings. Priming the inkwell, if you will. I also recruited column editors, like Ralitza Dilovska, Marie Poulin, and Kevin Potts; respected members in the community that had genuine concern for the project or a history of producing good content. I knew the extra keyboards would be essential.
By the fourth magazine issue, however, trouble in paradise was clear. Aside from the tremendous contributions from Stef Dawson, on top of his busy agenda as a Textpattern developer, and the initial efforts from column editors, the burden of writing was falling on me. I couldn’t let that happen. You wouldn’t want that to happen. So we stopped publishing until more contributions came in. They never came. I begged. I pleaded. I poked, prodded, and pushed. We made real-time adjustments with each magazine issue to scale the scope down, but it didn’t matter; we lost our momentum, column editors dropped away like flies, and article contributions dried up. And here we are today.
Correction, I did get offers from ghost writers; people with no knowledge of Textpattern whatsoever who were willing to come out of secrecy (perhaps with pseudonyms) and write any old fluff I told them to in exchange for link-backs and other self-serving requests. But I don’t deal with that crowd. As an editor, I have more scruples, and have higher hopes for the publications I’m responsible for. I wasn’t going to let the magazine become a content farm of listicles about nothing useful from nobodies. I stand by that.
I realise it’s hard to expect high quality and timeliness when you can’t pay writers for their efforts. But there was no budget for that, and I wasn’t paying writers out of my own pocket for Textpattern’s benefit. I wasn’t getting paid either. This was a community project as every Textpattern initiative is, despite not being a horse-by-committee affair. As such, I had hoped community folk—many of you quite knowledgeable of Textpattern’s nuances and capabilities from years of building Textpattern websites—would have come forward for the love of tool and clan, especially as I was providing free editing services to make your copy shine.
Frankly, a lot of designers could improve their writing. Developers, who often write for themselves, could too. Good writing is important for everyone in the digital age, and TXP Magazine was a great way for the designers and developers in this community to share what they know while brushing up on literary skills.
Alas, the editing team gave it a good shot, and I hope we had fun and learned from it.
In the time since the magazine has sat neglected, and my pride as an editor bruised along with it, I’ve come to realise that despite the promise of a magazine, the Textpattern community isn’t suited for one, certainly not the kind I had in mind. There are no writers, as of yet, to sustain a magazine, and the consuming audience isn’t big enough to turn that around. Original ideas like the Textpattern sites showcase, with accompanying interviews and tech profiles, and the theme design contests I hoped the magazine could sponsor, were off the charts of reality. Even the “issues” publishing model, which gave TXP Magazine a true magazine feel, was a challenge, unfortunately. It’s nobody’s fault. It’s just the way it is.
Reality demands something different. The community, if it needs anything at all (and maybe not), might benefit from something simpler. Something with less overhead, fewer editorial hoops, and a different audience scope. Something without need of a chief whip carrier too, though you can’t get rid of governance entirely, it’s important for quality control. Something back to the casual, open nature the magazine used to have, sharing a hodgepodge of information about Textpattern’s functional bits and bobs with no particular agenda, or whatever. And if we can broaden the magazine’s reach within the community by including non-English speakers instead of extending it outward from the community, then all the better.
My exit proposal, which assumes the domain won’t be retired, takes all of that into account and transitions TXP Magazine toward a new publishing direction. Let’s walk through it.
The plan began to emerge after a recent forum discussion with two people in Textpattern’s community who are not native-English speakers. Maybe you know them, their nicks are Sacripant and Milosevic. The idea began with the notion of relaxing the English-only publishing rule, which logically came from Textpattern’s policy of using English for official communication. Contributions from Textpattern’s many regional users could be cultivated by opening up the magazine to other languages. Apparently those segments of the Textpattern community are collectively greater in number than the English language segment alone, and are more interested in writing than their English-speaking counterparts too, according to the feedback I was getting, but the latter remains to be seen. Yet it’s a fair idea to consider, particularly as the non-English user segment lost a voice in the community when the forum and user documentation platforms stopped accommodating non-English dialogue. (Unfortunate, but sensible for overhead reasons). The magazine can be the new exception, giving non-English users an official channel to come together and share in a visible way.
The idea didn’t make sense at first because suggestions seemed to rely on translation efforts from one language to another. That would have made the editorial process more complicated, not easier. But then we recognized that by leaving translation out of it entirely, with a few exceptions for the static parts, the magazine would be a melting pot of regional languages for as many groups of readers. Such a model might succeed at achieving many things at once:
That’s a tidy sum of benefits, assuming the platform can be refactored to work, and the wave of contributing authors actually materialise. The former is probably doable; it’s software after all, just fix it. The latter is less certain, because as learned in this community many times before, building it doesn’t mean they will come. You’re expected to give feedback on this idea when you’re done reading.
An overview of the nuts and bolts will help set the stage, beginning with the most important part: content and audience.
The current incarnation of the magazine strived to reach people beyond (and including) the existing user community, offering vetted English articles that would attract web users in general, not just users of Textpattern alone. Some of the bigger ideas like the showcase and themes competitions were part of that thinking (which you may only now about if you read early issues of the magazine), but the main idea was that TXP Magazine could be a valuable web publication by itself, albeit with a Textpattern slant to some of the articles.
For the international transition, I propose we reel back on the audience reach, returning to the existing community of users, but specifically users in any language except English. That’s right, TXP Magazine would no longer publish English content, and no translations to English would be made for that platform. There are two good reasons for this.
First, which I’ve already mentioned, eliminating a translation step keeps editorial overhead down—way down—and this project needs to keep human resource demands as far down as it can because good human help is hard to come by (though it would be nice to have that help).
Second, plans are afoot to revamp the main Textpattern blog as a more open publishing system for English contributions from the community. It’s a great idea. So there’s no need to spread English writing efforts between two platforms. The magazine would serve international audiences, making them feel welcome and appreciated (because they are), and the blog will serve English language content specifically. A double win for Textpattern.
Content in the current magazine was designed as topics within subject columns. They had specific names, but essentially accounted for Textpattern tech, spotlights on noteworthy community people, opinions, and a wild card column for topic flexibility. Multiple articles—one per column or two max with some column variability—made up a given magazine issue. Within these columns, and notably the wild card, different topics could be addressed. From an IA standpoint, it worked well. From an article contribution standpoint against a reasonable publishing timeline, not so good. It relied on having several articles ready before an issue could go out, because a minimum number of articles in this case was needed for the ‘issues’ model to work.
Contributors to the international version of the magazine may like to adapt the issues architecture, or simplify it to a more linear, blog-like flow. Developers will appreciate the path of least resistance, of course.
That said, here’s one interesting idea for adapting the columns/issues model to make refactoring the architecture easier: Instead of columns representing different types of information, as they would with a single language, each might effectively be a wild card column (any topic goes), but dedicated to a given language that exists. A magazine issue would represent however many available articles there were at time of scheduled publication (a quarterly schedule might still be okay), but there should be no minimum (though at least one) or maximum limits per number of languages in a given issue. Odds that any maximum would be a huge amount are unlikely, thus not a concern.
The current magazine operated by a typical editorial process. A spreadsheet was used to schedule article assignments, and I used Asana to dole out other team tasks. Then it was the usual: authoring, editorial review, revising, publishing. A round of technical review was in there too when engineering topics were involved, as well as final image embeds and so forth once the draft was ported to the CMS.
Article drafting took place in Google Drive because it made collaborative editing easy-peasy compared to such work in Textpattern (not one of its highlights, but few CMS systems do collaborative editing right anyway). Google Docs have since added many new editing features, such as “tracking” changes, which is standard in Numbers and Word, so it’s great for even the non-techy types familiar with corporate options. Plus there’s no need to email anything around. (Draft is another collaborative editing option with nearly the same abilities, though the UI is less intuitive by comparison.) Workflow is supported by draft templates and writing guidelines, as expected.
Altogether the process is not hard, but it does take a willingness by the team to adapt to the chosen way of doing things. It’s the Editor’s thankless role to see that everyone does, as much as possible. This all works fine for classic publishing scenarios, where a team is involved and the content quality aims high, but it’s probably overkill for the new idea I’m proposing.
The scenario for the international magazine would be different by necessity. There won’t be an editor-in-chief at the top coordinating everyone’s tasks and scheduling what gets written. Instead, there would be a simpler review process (recommended for quality control), or no copy review at all, which probably isn’t possible.
In the latter case, the most basic, a hopeful contributing author would simply create an account, thereby agreeing to the established terms of service (to be written), and draft away as a freelancer, or some other named role in the CMS with similar rights. Even in this base situation, someone or something with higher system rights would conduct a technical check of the draft for any missing meta fields and whatnot, then hit the “Let’s do this!” button against a sensible date, whether ‘now’ or in the future. And who would be responsible for the post edits that always need to be done? Somebody has to be, or the quality of the whole platform will quickly go from abbreviated to lazy to another utter embarrassment. You can see the potential problems in this approach.
A level up on quality control would be better. A “Staff Editor” for each language might work, someone who stewards the publishing for that language alone. Language editors would establish their respective editing/collaboration workflows, however they thought best. They might like a typical routine with bells and whistles to produce the best copy they can, or pass drafts back and forth as email novellas. Whatever.
Because quality control is important, editors should be candidates from the Textpattern community, or at least vouched for by someone who is. A recognized language editor should exist before any articles are submitted for that language since someone needs to be in place to receive contributions, verify their structure against required CMS fields, and publish articles live when the time comes. In fact, that might be the mechanism for creating new languages in the UI; it’s only done when a language editor steps up for the role, and they should produce the first article for their language at the same time, even if it’s the only one they ever write. That’s their ticket in.
While quality articles in a given language are encouraged—and should be a sense of accomplishment and pride for authors and language editors alike—only readers of that particular language would ever know if grammar and such was shoddy. Nobody outside of a given language, including Textpattern leadership, will be keeping an eye on that language’s articles, or tapping the brand’s English style guide. The whole thing is largely an editorial trust system policed by the readership of a given language.
Developers would likely appreciate if the existing architecture could be reused as much as possible. Likewise, English content needs to be dealt with too.
So the first step would be to audit the magazine’s existing content—a relatively simple task since I thoroughly audited it once already and it’s now nice and tidy. Another quick once-over for this new initiative would be needed to cherry pick articles for potential re-publishing at the Textpattern blog. The rest would go on ice for another day, and redirects for everything would point to the magazine’s homepage. The end result is that no articles in English remain. No confusion for future non-English writers. A clean slate for new content.
Static docs, like terms of use, homepage blurbs, and so forth will need to be revised or written too, and perhaps that’s the only English content until those pieces can be translated. I’ll leave the specifics of that to developers. Any translation needs for static content would fall on the shoulders of the dedicated language editors.
Each language would have its own section where articles in that language stream. A standard presentation for all sections would be provided by default once the brand look and feel is completed by Textpattern’s designer, Phil Wareham. Depending on how fast things move along, the magazine’s current design is still lovely, and a few visual props like language flags or something may be all that’s needed to make it work. Ideas for custom presentations unique to a language are a discussion for later, maybe, when theme development has progressed further.
Each language would have its own RSS feed. The use of categories are variable, but taxonomic tags could be used to archive, filter, and search articles by topics, respective to a given language. Tags would require a single taxonomic tree against which all languages would be translated for their topics. Again, translation efforts here would fall on the shoulders of the language editor. The taxonomy tree is probably an early developmental need, so a community-generated list of terms might kickstart what determines the initial taxonomic.
The front-end will enable visitors to choose the language they prefer, provided the language exists in the system yet. No language option is shown until there is. Again, the establishment of a language editor, contributing the first article for that language and doing all needed translations of static content and taxonomy, is what gets a language started in the CMS.
For the admin-side and contributing authors, a language preference in the account creation process might handle what UI language they see. Each contributing author would have a freelance account, for example, to set up draft articles accordingly, and a front-end profile page to pimp their article contributions, much like the People section of the magazine provides for now.
Taking everything so far, you can imagine how this might look on the current homepage of the magazine. Internationalization conversions would need to be done, but mostly elements are removed, simplify the UI:
Sketches and technical briefs of all this stuff can be developed when the time comes, naturally.
You now have a reasonable idea of what the new concept would be. I do not presume to think everything I’ve laid out so far is the final word, and I’ve surely overlooked critical details. This proposal is meant to get conversation going, for your sake and that of the Textpattern project.
Textpattern needs you to indicate whether you like the idea or not, first of all, and then offer any additional thoughts toward other aspects of the proposal— notably on the user experience and overhead as it impacts workflow and system architecture. Come forth and speak. Otherwise this proposal will see no move on development, and the magazine as is will continue to grow mushrooms.
If you are a bilingual speaker, try and reach out to your language community and let them know what’s going on here. Start a new thread on the topic in your own language in the forum’s General discussion section and point people there to begin talking. Speak on their behalf, and give some indication back to the English thread about how much support there is from your hive. Consider being a starting editor for your language.
Go!
]]>