Support forums : Branches

localization nesting

Discussion about existing branches and the directions they need to go in, or, for branches that are going to happen. "Quickies" is wide open. "Branches" is more focused.

Moderator: Dracones

localization nesting

Postby EdB » Thu Sep 29, 2011 4:33 pm

https://code.launchpad.net/~quam-plures ... ation_path solves a problem described elsewhere in more detail, which basically boils down to this: get rid of the idea of a /php/ folder for localization.

For the global files it was pretty easy - just move the folder structure inside /php/ up one level and redefine the path to not bother with /php/.

For plugins & widgets & templates it was a bit harder because the file name now has to carry the language bit. Not too big a deal though. Assuming we go this way, the new structure for a plugin (widget, template) will be this:
myplugin_plugin/
-> po/ (folder)
-> -> index.html
-> -> messages.pot
-> -> _global.de.php
-> -> _global.fr.php
-> _myplugin.plugin.php
-> index.html
-> README.html

If someone wants to leave their messages.po file for the next person they'll have to figure out a nice way, which hopefully they'll figure out message.de.po or messages.fr.po OR figure out to put a /de/ or /fr/ folder in for their messages.po file.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: localization nesting

Postby EdB » Sun Oct 02, 2011 6:32 am

Extracting translations didn't work due to it liked the old path. Fixed, committing change at this moment. Also, the _global.xx.php file it writes also has a valid docblock so it doesn't piss off autodocs. Yay.

We really need to move this "extract" thing off the current Regional page and create a whole new interface for turning messages.po files into _global files. Templates and plugins and widgets currently get a manually created file or nothing at all. It'd be cool if we had a way to do all of them for any given language eh?
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: localization nesting

Postby Kimberly » Mon Oct 03, 2011 5:01 am

EdB wrote:We really need to move this "extract" thing off the current Regional page and create a whole new interface for turning messages.po files into _global files. Templates and plugins and widgets currently get a manually created file or nothing at all. It'd be cool if we had a way to do all of them for any given language eh?


I would expect that most third party plugin creators don't bother with translation files. So yes, this would be a good thing.

Speaking of languages; is Qaum Plures' native language US English, or UK English? Or is it a mixture of both depending on the coder?
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: localization nesting

Postby EdB » Mon Oct 03, 2011 1:44 pm

Kimberly wrote:... Speaking of languages; is Qaum Plures' native language US English, or UK English? Or is it a mixture of both depending on the coder?

In a very technical sense there is no difference. Which word is selected for what situation is localized, but it is also location-specific within regions of a nation. Simple example: for some reason in the south-eastern US States it is not uncommon for the person ringing up your shopping to ask you if you need a poke when elsewhere they would ask if you need a bag. "Soda" and "pop" are a more classic example.

The question is better asked as "formal or informal", and quite a while back the other app made a decision to go with 'more formal'. Oh wait I think in general it would be UK English with a strong focus on not confusing the rest of the world with word selection or grammatical usage. Can't recall the situation that triggered a long email discussion though.

Oh and here's another one for GPM to consider: apparently in some languages/cultures/locales "Joe USER" is an acceptable way to store the name when the person enters "Joe User". Totally pissed me off that it shouted everyone's last name. I'm pretty sure that one got undone.

Anyway it kinda seems like "English such that it sounds more business-like/formal and is unlikely to confuse any native English speaker" would be the rightest version. Having said that, I tend to go for the version of English that feels right at the time. An occasional "OMG LOL" is, in my opinion, perfectly acceptable no matter how fancy-pants formal all the text leading up to it may be. If that upsets the user then I'll refund their purchase price ;)
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: localization nesting

Postby EdB » Mon Oct 03, 2011 1:52 pm

Kimberly wrote:... I would expect that most third party plugin creators don't bother with translation files. So yes, this would be a good thing ...

I always make the .po file but have never made a _global.php (_global.xx.php) file. Perhaps a way for a coder to EASILY make a _global.template.php file would rock because generally there aren't many strings and they all come from the same file. Why bother opening PoEdit and doing all that stuff just for 10 or 20 lines right? Why not let someone open a template, make edits, and save-as whatever they are translating to?

Another thought on this area is based on how core will use the "core global file" if it doesn't find a localization in a plugin. Perhaps a setting for "run_through_plugins_and_extract_as_file" would let us automagically get some bits into a file, thus saving a bit of server power for each subsequent use of that bit of code?

Or not :)
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: localization nesting

Postby Kimberly » Mon Oct 03, 2011 8:46 pm

I think I was thinking more of the spelling differences. There are some differences in grammar as well. It is like with the title of this thread, Localization nesting versus Localisation nesting. Both are correct although the former is more likely to be used in the US with the latter more likely to be used in the UK. With programmers from different parts of the world contributing, it might be best to decide on which English is going to be used. Or, we can not worry about it and just let it go where it may depending on the coder.

O.T. CSS is an interesting example, it is US English. I am sure many UK programmers have entered colour without any thought; years of spelling it that way and the brain does it automatically, and then seeing the CSS did not seem to apply.
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: localization nesting

Postby EdB » Mon Oct 03, 2011 9:03 pm

Ah okay yeah there's another angle. I'm pretty sure going with whatever is ... standardized? would be the answer. For example for some reason spelling referrer as referer is what is in the standard, so the improper spelling is "the right way per that spec". Not sure if localization is the same sort of thing or not, but I kinda reckon somewhere someone figured out some sort of "standard", then someone else decided to write it up in the most boring convoluted obtuse language possible and put it up on an extremely boring website. Thus making it be an internet standard. gray and grey is another one, but "gray" wins on web pages. Actually I think "gray" wins per early specs but all browsers are smart enough to handle "grey" as "gray".

I got a great idea just now. Whoever is writing something can spell it any way they like. Obviously if spelling matters to the server or the browser then they probably want to spell it the way it works ;) and in code review someone might have a cow but in general assume the contributor to be contributing as they see fit.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona


Return to Branches

Who is online

Users browsing this forum: No registered users and 1 guest

cron