Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Updating the en-gb.txt language file
Hi, developer folks.
A little while ago I spotted some minor inconsistencies/goofs in the en-gb.txt language strings file. Having made the boo-boo of not noting them down at the time, I’m now starting to spot a few additional things that could be updated to improve/enhance the UX, without being bloated or onerous. British English is my first language, and I have a pretty good grasp of it after 30+ years speaking/writing it natively.
I’ve created a Github repo for en-gb.txt with a view to tackling each section at a time and making constructive suggestions for replacements or changes. Now, I’m mindful that there are a lot of small and not-so-small changes going though SVN right now, and I don’t want to impede that workflow by adopting a non-standard way of submitting potential changes. I’d like some advice before I proceed.
So, my questions:
- Is
en-gb.txta sacred cow that should only be modified by approved developers? I appreciate it’s bundled with core and therefore seen by many more people than strictly British English speakers, hence my question. - Should
en-gb.txtchanges be submitted as Issues in the Google Code SVN? If so, do you prefer monolithic or section-level changes/diffs? - Would you prefer suggested changes are RFC’d here in the forum first, or straight into the Google Code SVN?
- If I want to correct certain terms, who should I cite as approved references (AP, Yahoo! Style Guide, OED, etc)?
Thank you in advance.
Offline
Re: Updating the en-gb.txt language file
From a dev perspective, the Gold Master en-gb.txt file is generated at release time from the strings in the RPC so altering it directly in the repo is not going to help. We have to alter them on the server and they’ll filter down.
The method for doing that is just a user interface where we can alter one string at a time in one language at a time. Not sure of the best way to suggest changes, but a version-tracked en-gb.txt file is as good as any because we can diff the file and make the alterations.
One thing to be aware of though is that the RPC strings are universal and not bound by version. Thus any changes to strings are available immediately to all current and prior Textpattern versions when someone next updates their Language strings in a local site. We’ve had “fun” where we changed strings such as prev/next titles in 4.5.x along with a change to the way the buttons were rendered which meant that 4.4.1 sites have strange entities displayed on the prev/next buttons on the Write panel.
Sometimes changes benefit all versions and in an ideal world everyone would be on the latest version so it wouldn’t matter. But it’s just something to be aware of. If the proposed alteration would massively affect an older install then the cleanest way to deal with such disruptive change is to make a new string and change any references to the old one in the code. We don’t want to do this too often as it leaves redundant strings floating around in the RPC which get distributed with all new versions of the Textpattern; we can’t really delete them without breaking any UI running an old version.
I haven’t really answered your questions but hopefully you’ll be able to figure out the best course of action if you know the constraints we’re working under!
EDIT: Of course, a better solution long term would be to improve the RPC system so the strings were maybe tagged with a ‘since’ datestamp or a ‘deprecated/removed since’ datestamp. That way only the correct strings could be delivered to the correct version when Languages were updated from within Textpattern and nobody would get any strings from further up the development chain as the release date of the currently installed Txp would govern which strings get downloaded. Whether this is practical and how it would be managed is something I haven’t really thought about in any great depth.
Last edited by Bloke (2012-12-05 12:38:23)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Updating the en-gb.txt language file
Hi Stef — thanks for your reply, useful info. My comments inline:
Bloke wrote:
From a dev perspective, the en-gb.txt file is generated at release time from the strings in the RPC so altering it directly in the repo is not going to help. We have to alter them on the server and they’ll filter down.
Understood. My question really related to the best way of providing suggested changes in the way of patches rather than actually changing the source on RPC. You have the keys, I don’t — and that’s totally fine with me, I just don’t want to the be the problem tenant when you have a lot of things on your proverbial plate.
Bloke wrote:
The method for doing that is just a user interface where we can alter one string at a time in one language at a time. Not sure of the best way to suggest changes, but a version-tracked en-gb.txt file is as good as any because we can diff the file and make the alterations.
Good to know. On that basis, I’ll make suggestions on a section/chunk-by-chunk basis with supporting evidence. I’ll make these as Issues in SVN with appropriate diffs and links to the repo I mentioned, that way there’s an audit trail.
Bloke wrote:
One thing to be aware of though is that the RPC strings are universal and not bound by version. Thus any changes to strings are available immediately to all current and prior Textpattern versions when someone next updates their Language strings in a local site. We’ve had “fun” where we changed strings such as prev/next titles in 4.5.x along with a change to the way the buttons were rendered which meant that 4.4.1 sites have strange entities displayed on the prev/next buttons on the Write panel.
Understood. I’m not proposing anything ground-breaking, at least not right now, and I’m acutely aware of stragglers. I won’t have “fun”, don’t worry :) I’ll have a first pass today/tomorrow and submit a diff patch so you can see what I mean.
Offline
Re: Updating the en-gb.txt language file
Sounds grand. Thanks for looking into it.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Updating the en-gb.txt language file
Bloke wrote:
Sounds grand. Thanks for looking into it.
No sweat — I’m scratching an OCD itch, so we both win :)
Opened issue #334 with some initial thoughts.
Offline
Re: Updating the en-gb.txt language file
Actually GitHub is not a bad idea when it comes to language files, maybe we could utilise it to help flesh out some of the languages that have not been maintained very well, with a request for helpers. I wonder.
Offline
Re: Updating the en-gb.txt language file
philwareham wrote:
Actually GitHub is not a bad idea when it comes to language files, maybe we could utilise it to help flesh out some of the languages that have not been maintained very well, with a request for helpers. I wonder.
Smart move. +1.
Offline