Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Front side theme - text direction
Sounds like the RPC server could be fairly easily phased out in a future roadmap. Releases could be handled by the .com site and I don’t know what benefit pinging home as, I’ve never seen any stats to back that up.
The pophelp files would need to be moved somewhere, maybe they can be integrated into the Textpacks GitHub repo Jukka has just created?
Offline
Re: Front side theme - text direction
Bloke wrote:
In my slightly misguided opinion, the lang_dir entry should NOT be in the translation files at all: that itself is a hack. It should be meta data applied to the file itself, like its name/ID and its language label. If you look inside every lang file you’ll find entries like this:
Any language related data absolutely should be in the language files. Each language file should information about:
- The language’s localization code.
- Contain the language’s localized name.
- Its direction.
E.g.
lang_dir => ltr
lang_name => Italiano
lang_code => it-itThese all can be as their own entries in the file. Contributors just have to follow the directions, which now is much easier than with some horrible closed server.
one lang code item for each language. Again, they are special entries and should not be translated, even though sometimes they are, by mistake.
Those definitely should not be in the language files. The language name can be extract from each language itself.
philwareham wrote:
The pophelp files would need to be moved somewhere, maybe they can be integrated into the Textpacks GitHub repo Jukka has just created?
Maybe to an other repository, not that one. I can extract the data and build the help system, if I can get access to the said data. I have to be able to see them first. After which I’m going to generate JSON from each entry (or Textile which is then built to JSON etc).
Depending on the size, help files could, or rather should, be bundled in the Textpattern release downloads. Currently they are not versioned so the information becomes irrelevant to older releases when updated, or interface changes.
If we still want to use server, its possible too. Just deploy the repositories to some directory on Textpattern.com server.
Last edited by Gocom (2013-08-15 10:03:08)
Offline
Re: Front side theme - text direction
I can download an SQL file of the RPC server database, you can have that if you want. Can extract the help files from that maybe?
Offline
Re: Front side theme - text direction
philwareham wrote:
I can download an SQL file of the RPC server database, you can have that if you want. Can extract the help files from that maybe?
That would be great. That would definitely work; just would have to run it to MySQL (and small script to extract JSON or some other file format).
Offline
Re: Front side theme - text direction
I’ve now added Textpack support to the Composer installer, which is one step closer to getting this all together:
https://github.com/gocom/textpattern-installer/commit/33b169c36b5aec1b45ec327fb6286ce21dc19d9b:
Supports Textpacks.
Textpacks are moved to the textpattern/lang/ directory,
assigned under a provider.Core Textpack for instance would be found from:
textpattern/lang/textpattern/textpacks/While John’s additional amendments would be located
in:
textpattern/lang/john/textpacks/Now we need to update the language panel,
Textpattern setup script and build scripts and we are
all set.
Meaning that we can use that in our build scripts (Composer to get the Textpack for the release) and it also allows others to create their own super-sets of translations and distribute them through Composer. The installer already also supports direct Textpack installations (to DB) via plugin type packages.
Need to at some point move (or clone actually, can never really remove the repo because of Composer, even that no one is actually referencing the full repo URL) that Composer installer repository under Textpattern GitHub account (haven’t done it yet since the repository is the package – moving may cause small unexpected issues with Packagist and Composer – probably at least may invalidate cache, have to check first).
Offline
Re: Front side theme - text direction
Gocom wrote:
Each language file should information about: The language’s localization code. The language’s localized name. Its direction.
The localized name: absolutely. The lang code, well yeah, it won’t hurt, though in order to get at the right translation file in the first place we need to know the code anyway so this is ‘known’ information before reaching the file itself, which could be classed as redundancy. But having the string parsable by gTxt() might be useful in some cases.
As for the direction, I dunno. Yes it might be handy to have it as a string so it can be displayed via the <txp:text /> tag, but the problem we’ve had in the past is that some translators who see the English ‘ltr’ entry and don’t know what it means have translated the text “lang direction” instead, which messes things up for the admin side, among other things. That’s the only reason I would prefer it to be meta data rather than a translatable string, so there’s no confusion. Or put it in a special section of the file that is clearly delineated as “Do not translate these entries”, written in the local language. That’s doable as long as the parser knows to skip comment lines. Think it does that already, can’t remember.
I agree about putting the lang name as a string in each file and removing the duplicated entries for each language. It does make creation of a master lang list (e.g. as used on the Languages panel) a bit more file-intensive as it needs to read each lang file to discover its localised name, but maybe with some cacheing that load can be reduced.
To do this properly we would need to ship the entire set of lang files with Txp, which is probably how it should be done anyway. Possibly with the option to pull new versions from, say, GitHub between releases if translators have made pull requests and there have been alterations mid-release cycle that weren’t there at release time which affect the current release.
I don’t know if we can presume that, at release time, all new strings will be available and translated with the bundled package. They are likely to be added piecemeal over time after a release, right? Like they are now? That’s one thing the RPC does for us which is handy, but it’s not done well enough behind the ‘closed shop’. As we all know, with little or no release-based versioning it gets messy if people update their local string bundle in older versions of Txp, as the newer strings might have changed (the next / prev buttons on the Write panel show this problem if you update Txp 4.4.1 with today’s strings). But maybe with tagging and/or better versioning, sprinkling some GitHub magic dust, this situation can be improved?
Last edited by Bloke (2013-08-15 19:31:42)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Front side theme - text direction
Because we control whether pull requests are merged into the GitHub repo we shouldn’t have a problem with strings being translated when they shouldn’t be, because we’ll peer review any patches and catch those errors. That also stops the blind additions that are currently made by translators using the RPC method. Who are these mystery translators anyway – I have no idea. With GitHub everything is done in the open and the result is publicly viewable.
Moving forward I vote we should bundle language and help files into releases, and have them also available for update between releases by using proper versioning.
Offline
Re: Front side theme - text direction
Bloke wrote:
That’s the only reason I would prefer it to be meta data rather than a translatable string, so there’s no confusion. Or put it in a special section of the file that is clearly delineated as “Do not translate these entries”, written in the local language. That’s doable as long as the parser knows to skip comment lines. Think it does that already, can’t remember.
Don’t see the point. They know what its for, since its either or value in all the other translations. If they mess up, then they mess up. Not hard to correct or notice, since the files all in a vcs.
It does make creation of a master lang list (e.g. as used on the Languages panel) a bit more file-intensive as it needs to read each lang file to discover its localised name, but maybe with some cacheing that load can be reduced.
Not really. It needs to read about first 60 bytes per file, over 40 queries. Reading doesn’t take much memory, neither time. Caching isn’t necessary; we aren’t reading the whole file, of course, but merely extracting the fourth line (or precisely the first instance of lang_name string).
To do this properly we would need to ship the entire set of lang files with Txp, which is probably how it should be done anyway.
Yes.
Possibly with the option to pull new versions from, say, GitHub between releases if translators have made pull requests and there have been alterations mid-release cycle that weren’t there at release time which affect the current release.
Textpattern installation itself will never be able to communicate with GitHub, so no. There is going to be no communication with a server, or at least GitHub’s server. You can of course update your Textpacks with Composer or by download them from the repository, but distribution happens entirely with Textpattern releases and patch updates.
But maybe with tagging and/or better versioning
Of course we are going to do proper tagging and branching with the repository, allowing anyone to download matching translations for their Textpattern version, or keep updating older version trees.
Offline
Re: Front side theme - text direction
Gocom wrote:
If they mess up, then they mess up. Not hard to correct or notice, since the files all in a vcs.
Oh yeah, forgot that pull requests are merged by hand. Fair enough.
You can of course update your Textpacks with Composer or by download them from the repository, but distribution happens entirely with Textpattern releases and patch updates.
Makes a lot of sense. Much cleaner and less confusing than the current mess.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Front side theme - text direction
Bloke wrote:
Oh yeah, forgot that pull requests are merged by hand. Fair enough.
In addition we use CI that run automated tests, and that we do have tests. Notice that, hopefully green, Travis build status badge in the README? Travis also emails all of us about failed tests, and automatically checks any incoming pull requests.
I’ve even added a test for the direction and the language code. I still need to add newline style check, and one for string length. Possibly one for HTML and unescaped special characters too (strings do need to be sanitized for HTML — chevrons and straight quotes need to either be escaped, or unicode alternative used).
Offline
Re: Front side theme - text direction
Bloke wrote:
, but the problem we’ve had in the past is that some translators who see the English ‘ltr’ entry and don’t know what it means have translated the text “lang direction” instead, which messes things up for the admin side, among other things.
At least on the admin side, a fail-safe could be to check the value: it must be equal to ltr or rtl. If not, it defaults back to one of those 2 values.
Offline
Re: Front side theme - text direction
Jukka added tests to the GitHub repo which prevents the wrong value, or missing values, being put into lang_dir string (Travis CI will send each of the devs a message if the test fails). Along with us peer reviewing any new pull requests, that problem should cease to exist.
Travis CI is great.
Offline