Wedge

With the changes to user, I had to specify a parameter (error type is param 2, sprintf vars is parameter 3). Where the type was specified I was fairly sure I'd got it right and where it wasn't specified (and thus it would be logged as general), I changed it, at the time it seemed more logical to flag it as a user error rather than a general error. It's not a general error in processing, it's because the user has done something wrong - and that to me makes more sense to flag as a user error.

Pete -- there are so FEW fatal_error() calls left, I think it'd make sense to actually rename them to fatal_error_hardcoded() or something (who cares), and rename fatal_lang_error() to fatal_error()...

I used a mix of my own memory and Google Translate when my memory failed me. I knew it probably wasn't perfect but I figured I'd give it a shot, and while I haven't had time to check the fixed translation, I'm willing to bet that not having 'here' in a separate string (for example) allows for better translation.

No, it shouldn't be $txt[$error] passed to the update counter, it should be the $error on its own - the second parameter indicates where it came from, false for fatal_error, true for fatal_lang_error, because it deliberately doesn't stuff the entire message into the online table if it doesn't have to.

The removal of the %p test in Subs... At the time I concluded it was redundant; the only language that I'm aware of that uses AM/PM in a 12-hour context is English, and I don't know any other language that prefers a 12 hour context over a 24 hour one.

I can reinstate it but frankly I'd rather push English to 24 hour before I supported 12 hour more...

Where else is $txt['with'] used?

If it's not used anywhere, remove it. Also check for merge_ on its own, strings get compounded a lot in the code.

As long as it's decoded back into $txt[$error] on the other side of the log viewing code...

I don't know either but I'm no specialist.

Really?

Nowhere...

But I just couldn't find...

Remember that AM/PM support was very late in the day, not only as a fix but as a report. It can't be that big a problem. It would be interesting to see what languages actually have updated $txt['am'] and $txt['pm'].

Support is very limited. All it does is search for %p, work out whether it's AM or PM and substitute in the relevant $txt item. Since I removed the $txt items and the test... it is all gone. Basically it just brings us back to around 2.0 RC4 - but the language itself now dictates what format to use, rather than a language independent version set by the admin.

Quote

Nowhere...

Kill it. If it isn't being used, get rid of it, pure and simple.

Regarding the latest few commits... Wouldn't it make sense to have a function like, 'complex_string', whose purpose would be to do the common string replacements? (boardurl, scripturl...)

I totally forgot that this was recent, indeed...
I don't even know why people would need to translate this, meh.

Or simply remove the comma entirely..?
I really like not having the year when it's a recent post... It's halfway between hardcoded and dynamic dates. And it saves precious space.

We could also kill $txt['by']

t's just that in Japanese, the 'by' is usually shown after the name. But I think it can be put before the name as well, if needed. It just doesn't feel as natural. (And yeah, I know, even SMF doesn't have a Japanese version... But Kyôdai Mahjongg does

It would indeed be slower, though I'd suspect it would be much more convenient to use something like <we:script> and replace it in the buffer at the end. It would certainly avoid juggling the variable about so much.

It's not so much that some people need to translate it, it's more than some languages simply have no concept of am/pm, and use 24 hour systems instead. In fact, I think it is a peculiarity of English the more I read up on it.

Hmm, I'm not actually that fussed personally. I'd say that whatever is reliably going to strip it without leaving too much fluff is fine.

http://download.simplemachines.org/?smflanguages disagrees with you.

What would really help is if I could talk to people who know more languages; ideally I'd like to speak to people who know Chinese, Russian and Arabic. While I'm aware it's a gross simplification, Japanese, Chinese, Russian and Arabic between them hit up all the key problems in the language files.

Internationalisation is an incredibly complex art,

For example, I'm aware of the whole use of : in strings in the admin panel and other places. My gut instinct tells me that they should be in the language file, not the template, because from my understanding of RTL and the way it's currently handled, you'd risk ending up with <setting> <string>: rather than the more correct <setting> :<string>. But I don't know any RTL languages, my knowledge of French is limited and rusty, my knowledge of other languages even more so (but it's enough to recognise that the constructions used currently do not work consistently outside English)

We'd only need to call complex_string on strings that we KNOW to have variables in them. In effect, it doesn't represent a lot of strings.

I'd tend to say that it's up to the server to translate that to the current locale

$scripturl is the special case, because it's used in a ton of strings as well as throughout the source.

@Nao, that's why I suggested doing it with a <we> variable ;) it won't ever be used in posts directly.

But if it's a global replace, you can replace any instance of scripturl throughout the entire source, except for its definition in QueryString, and the actual replace itself.

Why not..?
Do you think {scripturl} is likelier to be used in a post? Well, if it's used, it's only to explain users what it's for, or post code samples etc... <we:script> would be in the same situation, wouldn't it? (Also, it would be caught by the macro replacement code AFAIK...)

QueryString....?