Front side theme - text direction

philwareham · 2013-08-14 15:42:20

Nice. I’ve already made a couple of amendments.

Can we list the language strings in proper alphabetical order within those files? I’ve noticed many missing strings between the different files and listing alphabetically would help me track down all the errors.

For example, the en-gb file (which is our base language file from which all other language files are supposed to be based on) has 1249 lines – other language files don’t have the same number of lines as that, indicating a number of missing strings.

Once we have these in some sort of good order I’ll shout about it on Twitter and see if we can get some action on the missing translations.

Bloke · 2013-08-14 15:55:21

philwareham wrote:

I’ve already made a couple of amendments.

And therein lay the problem. That was why we needed the horrendous duct tape in the first place, because the language direction was seen as a string that needed to be translated rather than a value that should only be one of two three-letter character sequences. Namely ltr or rtl, exactly like that.

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:

is-is => Íslenska
it-it => Italiano
...

one lang code item for each language. Again, they are special entries and should not be translated, even though sometimes they are, by mistake.

They are meta/attribute data about each language and should not be inside the files themselves as translatable entities. That also needs fixing somehow. A master list of available languages and their properties (like I alluded to in my first post in this thread) is one way, doubtless there are better methods.

Last edited by Bloke (2013-08-14 16:01:53)

philwareham · 2013-08-14 16:06:51

@Bloke Very true. There really is no need for those to be in each language file.

philwareham · 2013-08-15 09:13:47

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?

Gocom · 2013-08-15 09:59:52

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-it

These 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)

philwareham · 2013-08-15 10:40:04

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?

Gocom · 2013-08-15 11:10:39

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).

Gocom · 2013-08-15 12:50:32

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).

Bloke · 2013-08-15 19:28:28

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)

philwareham · 2013-08-15 20:00:34

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.

Gocom · 2013-08-15 20:18:25

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.

Bloke · 2013-08-15 20:24:15

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.

Textpattern CMS

Textpattern CMS support forum

#13 2013-08-14 15:42:20

Re: Front side theme - text direction

#14 2013-08-14 15:55:21

Re: Front side theme - text direction

#15 2013-08-14 16:06:51

Re: Front side theme - text direction

#16 2013-08-15 09:13:47

Re: Front side theme - text direction

#17 2013-08-15 09:59:52

Re: Front side theme - text direction

#18 2013-08-15 10:40:04

Re: Front side theme - text direction

#19 2013-08-15 11:10:39

Re: Front side theme - text direction

#20 2013-08-15 12:50:32

Re: Front side theme - text direction

#21 2013-08-15 19:28:28

Re: Front side theme - text direction

#22 2013-08-15 20:00:34

Re: Front side theme - text direction

#23 2013-08-15 20:18:25

Re: Front side theme - text direction

#24 2013-08-15 20:24:15

Re: Front side theme - text direction

Board footer