netcarver

Glad that helps & yes, I use gvim most of the time.

Ok, I got some follow up from a helpful RTL language user from the Textpattern forum & things are different to what I initially memory dumped. I started off by having Google translate the greeting "Hello"[en] into [ar] and got "مرحبا" as the result. My friend confirmed that "م" is the first letter (looks slightly different in the phrase as it joins to the next char) and "ا" is the last character. I then put together a small test page that puts out both the English and Arabic with various combinations of the dir and lang attributes to see what effects these have on the renderings and looked at the output in Firefox and Chromium. A summary of the results... Both browsers render the test output identically. The dir="xyz" attribute only seems to control the alignment of the output, not the direction in which the string is rendered: the browsers themselves seem to be figuring out the correct way to render a sequence of characters. The lang="xyz" does not change the alignment, nor the directionality of the rendered output but does make a difference to the font selected to do the rendering. It seems that the editor you use to view the source file does make a difference to what you see in the php. On my linux box gedit renders the Arabic as RTL within the quotation marks, whilst Vim renders it LTR. A hexdump of the php shows that the Arabic string is indeed stored in the file with the first character following the opening quote mark and the last character before the close quote. So, whilst vim shows it literally, it looks backward (to an Arabic reader.) Hope that helps.

I'm chasing this up with a RTL language user from the Textpattern CMS forums as my recall of this aspect is poor and may be incorrect.

Are my old eyes deceiving me or is there a spurious return at line 47 in wire/modules/SessionLoginThrottle.module -- or am I totally misunderstanding how this method works ? public function sessionAllowLogin($event) { return; $name = $event->arguments[0]; ...

Hi Ryan, thanks for the reply. Yeah, they certainly draw the eye so I do get this as a positional anchor in unfamiliar text. I guess I'm pretty biased as I lived in Malaysia for a number of years and there are four commonly used languages there (English, Malay, Chinese and Tamil) but one flag. Yes, you could chose the US or UK flag for English, the Malaysian for Malay, the Chinese for Chinese and the Indian for Tamil but for sites aimed at a domestic audience that would force many viewers to identify with outside nations when the majority of visitors would be Malaysian. Despite my personal preferences, the use of a consistent markup of language codes as CSS classes gave site designers using the MLP Pack the flexibility to implement a number of alternate selection schemes. In fact, many sites that were made with the MLP Pack simply used CSS to add flag icons to their rendering of the site's language choices. If you keep all your flag icons in a common directory and name them according to the language code it's trivial to do. Yes, and it also stops your browser caching the incorrect language output for a given URL. The use-case for the above was for when visitors would omit a language code from the URL, if the language code was present they'd always get the same text. Looking back on it, it does violate Google's guidelines for missing codes. Not aware of any. If I remember correctly, you still treat all your strings internally as left-to-right but the browser just starts over on the right-hand side of the containing block and works over leftward when rendering the strings in rtl blocks. [Edited to add: I may be remember this wrong as a non RTL language user myself. I'll see if I can chase up some RTL language users from the Textpattern CMS forum and check it out.] So this php... $out = "abcdefg"; echo '<div dir="ltr">' . $out . '</div>'; echo '<div dir="rtl">' . $out . '</div>'; ...would render text like... abcdefg gfedcba I do remember there being some very strange looking rtl output for strings with punctuation, though I can't give any concrete examples here. Edited to add: The above example is incorrect. Following further testing (see below) the output is as follows... abcdefg abcdefg and the direction of the string itself seems to depend on the code-points used in the string with the browser automatically rendering them as required.

Hello formmailer, As exchange rates usually vary quite slowly, how about just caching the last value you successfully get each time and fall back to that if a read fails. You could also have your module email you if reading fails a number of times. Edited to add: This might not be acceptable for some applications that may require a certain amount of 'freshness' to the data or to data from sites where the TOS forbid caching.

Ah, that opens up quite a lot of flexibility that my scheme didn't have without resorting to adding non-standard entries to the array I posted. I can see how that could work well for languages tailored to specific roles or domain knowledge, mainly in the admin interface I would have thought. BTW, I did things this way in the MLP Pack as there was a lot of utility in combining the codes used for the HTML lang & dir attributes and the localized script names in public facing applications, not just in the admin interface. In public facing multilingual sites I wanted new visitors to be able to quickly locate and switch to their language of choice (if available) which is probably still best done with the local script name rather than something more arbitrary. There are other solutions to presenting such a selection rather than using some string. For instance, some sites adopt the use of flag icons to indicate language choice. I personally think this is a bad idea. Flags intrinsically represent nations, not languages, and there is seldom a one-to-one relationship between them (at least not now) and for residents of the many multilingual nations (like India, Canada, Malaysia, Indonesia, Singapore etc) using flags as language indicators just doesn't make sense. Linux installers take the local script name route too, presenting a big menu of language choices using the names for the language in the native script. That kind of covers the first base: what to call (label) your language choice. The other base is the use of standard language codes -- which it sounds like you have covered as data in the translation files. Using the standard language codes also allows you to implement automatic language selection. For example, most browsers will submit an Accept-Language request header using 2 character codes. Server side you can pull these codes out of the headers and use them to auto-select the correct (or best) language for your visitor's browser and fall back on a site-wide default as a last resort. Even then you'll probably still need a language selector of some kind that makes sense to the visitor as often the visitor will not have configured (or cannot configure) their Accept-Language headers to correctly identify their preferred language. Apologies if most of that covers ground you have nailed in PW, just dumping it in case. The RTL support in Firefox seems pretty good to me but I can't really speak for other browsers. RTL layout is triggered by marking up an applicable place in your HTML with a dir="rtl" attribute (or "ltr" or "automatic"). You can apply this markup to multiple page elements as required and even nest them. So if you had an English document which quoted some RTL language like Urdu (ur) then you could do something like <body lang="en" dir="ltr"> and then mark all the block quotes with lang="ur" dir="rtl". I didn't take RTL support any further than this and several RTL language users in the Textpattern community seemed happy enough with it.

I know I'm coming to this late and that Ryan has put a lot of effort into the multilingual features in pw. I'm not sure if this will be of any use or interest for presenting a language-select feature in pw but here's a gist of most ISO 693-1 Languages in their own script and includes direction rendering information for those that render right-to-left. Encoded in utf-8 so should render correctly if you have the necessary code-points installed in a font on your system and it also includes a few regional variations (eg. for Taiwanese vs mainland Chinese.) I just pulled this out of my, now rather outdated, Multi-Lingual Publishing (MLP) Pack for Textpattern CMS.

Sure, but I'm pretty dumb and would probably forget to add the multiple files that MySQL creates behind the scenes for each new table I may end up adding to my database. SQLite would be easier in this respect. As I'd probably create and modify templates more frequently than I would add tables, I probably wouldn't have the same issues remembering to add the template files to the repo.

Ok, look forward to that. At least I'd have some confidence that my tinkering wasn't breaking things -- or an early warning if it were. Sounds good. I guess eventually having SQLite support would give another option for this too as you could just put the single DB file into your set of tracked files.

Hi adamkiss, Ok, so could I just version control all the files in the /site directory? I guess I could, that would kind of make sense.

Not sure if this is the best place to post this but here goes anyway. As a followup to my initial installation of pw, I just did another and sat looking at the final set of messages from the installer for a while thinking something looked a bit, err, disjoint with a couple of the messages. In the list were these two, not next to each other in the list, but in this order... Now that the installer is complete, it is highly recommended that you make ./site/config.php non-writable! This is important for security. There are additional configuration options available in this file that you may want to review: ./site/config.php Now, as a total newbie to pw, if I do the first I won't be able to do any editing that might be needed in the second part of the message without undoing what I just made read-only, then applying my edits and making it read-only again. Ok, I guess that in most cases, the second stage will be a review with no editing needed. But that might not be the case -- and might even change in future versions (another guess.) So perhaps these two could be rationalized into one, something like... "Now that the installer is complete, please review and, if needed, update the contents of ./site/config.php before marking it read-only. NB: For security it is highly recommended that you make ./site/config.php non-writable!" Would this simplify things for newbies?

Hi Alan, Haven't we met before somewhere? Anyway, you are almost there with your code. Welcome to the world of regular expressions. Now, to go from... // _What are hedgehogs?__Hedgehogs are ...to... // What are hedgehogs?_Hedgehogs are You need to do a couple of extra steps if you want the PHP workout and can't find anything else. If you store what you want to echo in $out then do this (I'm showing it in two steps but you can combine if you want)... $out = strtr( $out, array( ' ' => ' ' ) ); // All double space runs to single space runs $out = trim( $out ); // No leading or trailing spaces. echo $out; You should get your target result.

@Ryan, Out of curiosity, is there a set of unit tests/fixtures for pw? Something that folks could take and use to ensure stuff they were working wasn't breaking anything? I didn't spot anything during a brief look at the pw directory structure.

Hi Folks, Very informative topic, answers several questions I had about the DB choices in pw. I too would like to see pw adopt a more flexible attitude to backend DB engine and even sub-engine as I have found InnoDB to be a more reliable storage engine than MyISAM in MySQL. I see that InnoDB, too, has recently gained fulltext index support so I hope whatever DB extensions make it into pw also include a MySQL+InnoDB option. Further, and keeping with the Textpattern theme that kicked off the topic, there seems to have been a recent trend amoung some Textpattern users to move Textpattern's presentation elements (pages/forms/styles) out of the DB and onto the server filesystem (at least while sites are under development) in order to allow them to be placed under version control. I do this myself for some sites I develop in Textpattern and there is a useful plugin that facilitates this. Is the same possible in pw?

Hi Adam, Sorry, I totally blanked on your initial reply to apeisa so I missed your link to Neon. I'll check it out. Ok, took a look and you're right. Neon looks more flexible regarding leading tabs / spaces but lacks a lot of YAMLs more complex features -- which may well be fine for this application -- and it gives you good error reports. However, I think my general point may still hold true if people who aren't familiar with the leading whitespace requirements end up editing those files, and especially if the parser errors are not exposed fully to the user.

Hi, A thought on YAML: whilst it is a very nice format (I use it for test fixtures) please be aware that it is whitespace intolerant as it uses leading indentation/spacing to delimit structures a bit like Python or HAML do. You need to configure your editor carefully to preserve existing leading space if you are to work with YAML files. If it is just you going to be editing these then that might not be a problem, but once users of your system start editing them you could be in for some extra support work if they don't configure their editors well. I've used a single file library called spyc before and found it very effective at meeting my YAML processing needs.

Hello all, First time user of pw here and I like what I'm seeing; a lot. Ryan and all the contributors have done a great job on this project so thank you to one and all. Coming from a background writing plugins for Textpattern CMS I thought I'd start off looking at the modules system. Being able to git clone a module right into a test installation is very nice but I quickly found myself having to scroll through lots (and lots, and lots) of entries to locate the first module I cloned before I could hit the install button. Soooo, I took a look a the code and decided to simply have the message about newly available modules link to its entry in the list. Makes installation much less scroll-prone. You can check it out for yourselves at https://github.com/n...ver/ProcessWire and I've submitted this to Ryan as a pull request. Hope this is useful to someone here.