Wedge

Neither did I :)
It was already in SMF2, if you want to have a look!Yup.
Thanks for doing it in the latest rev, BTW...!

I just have a note about the moderation filter for link count... They won't take [URL] tags into account, will they...? i.e. they're case-sensitive here. Is it as desired?

Yes, it will. First thing it does is strtolower the string.

Oh sorry, missed that :)

I'm currently looking into the index language file. (Also translated the moderation filter stuff.)
It's very interesting... There are plenty of strings that simply aren't used anymore in Wedge (and probably in SMF too), and they're still in the index file...
Obviously I'm removing them, but we'll have to be careful whether or not they were actually used by modified in such a way that they can't be found with a simple search on the name :)

For instance, $txt['time_offset'] is no longer used anywhere but in the Profile template, so I'm moving it over there.
Also, template_profile_timeoffset_modify() seems to be a leftover from the previous system. Did you keep it "just in case" or was it an oversight?

The thing about legacy strings is that they're sometimes used in composite form elsewhere e.g. $txt['something_' . $something] so while it might not be obviously used, it may end up being used anyway, as you mentioned, though some of them will just have to be tested to see if the string isn't used, heh.

The time offset stuff is deprecated, but I didn't remove it pending finishing (or reverting) the timezone stuff.

That's what I mentioned in the changelog... And that's after checking for multiple possible composites, really.I think SMF is wayyyyyyyyy too cool when it comes to outdated strings... The move to SMF 2.0 wasn't smooth.Okay. And not need to remove it... Tss :P

No, the move to 2.0 wasn't pretty, I wasn't involved but I was aware that 1.1 used numeric indexes and that there's even hints of that still in Wedge (e.g. the movetopic strings I moved yesterday, being numbered 1 through 4)

But either way, we're definitely moving in the right direction.

Yup... And there are even more useless entries in index. You have no idea the number of crap that should be in Login.language.php for instance... :^^;:

Oh, and this $txt['times'] thing... Another generic thingy that isn't used anywhere, to my surprise. (Feel free to double-check.)
It also has a $txt['attach_times'] entry that has the same content. (Very smart...)
So I removed both 'times', and made a single string for both attach_downloaded and attach_viewed or whatever.
Then I figured, okay what about adapting it for "Viewed 1 time"... Instead of "Viewed 1 times"...
So I changed it to attach_viewed_n and attach_viewed_1. But in French, times is 'fois', which is both singular and plural, and I don't want to have to set a dummy attach_viewed_1 for it just because it'll show the English version instead...
Reminds you of the month days, doesn't it...?
I think maybe there's an issue in how we're handling number_context. Maybe we should use an array for every single entry... I know, doesn't sound great, and it may actually slow down Wedge (by a few microseconds), but I don't know how to do it otherwise.

I'm glad to see you guys tackling these internationalisation-related issues, really. :)

(BTW, your ManageTopics files were in Windows CRLF format. I tend to double-check for new files so I caught it and fixed it. Try and have your notepad app generate LF files by default :))
(Also, maybe it should be renamed to Topics.language.php?)

Oh and thanks Aaron. Pete is all the more commendable for this because by definition his native language doesn't require any work :P
I'm still lazy enough that I only deal with stuff that makes Wedge better in French. Just like Spip (my fave French CMS which I used back in 2003) had excellent French support.

Oh, sorry, yeah, this is a mostly new install of Notepad++ which I forgot to reconfigure for LF only. When I first made the file I actually called it SplitTopics because it was just the stuff for SplitTopics.php (namely splitting and merging) but then I moved the topic-moving stuff in as well.

Thing is, it's totally related to managing topics, rather than topics in general, hence the name.

And thanks Aaron :) Certainly I find that I forget some things, notably dates and times which Nao's done a lot of work on, but for the rest of the things out there, I've got a fair idea of how I think it has to work to actually be meaningfully suited to i18n, and the biggest thing is tackling these awkward composite strings where a single line is made out of $txt['something'], $variable, $txt['something_else'], because that causes so many problems!

I am aware though that some of my moderation filters UI won't work properly in RTL because of the way it builds certain strings but I figure to a point we'll deal with that when there are people around who actually use an RTL language and can be best placed to tell us how it has to work. I'm not familiar enough with other languages to make that much of a call on it.

And actually while my native language doesn't require me to think outside the box in terms of phasing out composite strings and bringing in sprintf type strings, it does make me acute of how to cope with multiple languages at once, and I'm still not sure how exactly I want to handle English US vs English UK though I know I will want to do just that. (It makes me chuckle that phpBB has the exact opposite problem, having a strong British heritage)

Without wishing to sound like I'm taking a cheap shot at SMF (because I'm not), I'm a bit concerned how they're planning to solve this fundamental problem in the future. I can't remember when it was logged on the tracker, but AngelinaBelle (IIRC) logged an issue to deal with these composite strings, and the general approach was to create multiple forms of the relevant words for composite elements, so when you had some of these, you'd have multiple different words depending on the context, e.g. $txt['members_normative'] and $txt['members_declarative'] which in English would be the same string but would be different strings in other languages, I think it was talking about German.

But instead of doing that, I figured it's simply cleaner and easier (if very slightly slower) to create the complete string so you always have the term in relevant context.

Still, it's not like XenForo or other systems where we put it all in the DB...

Hey yeah, it's not a problem :) I did my share of CRLF commits too...!For now it's okay, even though I moved SendTopic strings there.Yep, and sometimes it's annoying to find some generic strings that are found across different files used in multiple strings...

BTW, you didn't tell me whether you thought it'd be best to rewrite number_context to use an array directly?
Oh and we could for instance put a string instead of an array, and that would mean 'no special treatment' (i.e. always '_n'), meaning that instead of doing sprintf() on strings, we could directly call number_context even if we don't have special treatment for them in French or English -- because it doesn't mean other languages won't need it...

Also -- I looked into loadLanguage and it has an oddity.
loadLanguage('index+Errors') would be an acceptable call. It will explode the string and deal with both language files.
However:
- it could benefit from being turned into an array parameter, like loadSource etc...
- currently, $already_loaded stores the entire string in its cache. Meaning that if we did loadLanguage('index') and then someone did loadLanguage('index+Errors'), the index file would be loaded a second time. It can be fixed by moving the caching operations to within the foreach, and using a continue; instead of a return $lang, but I don't know if it's acceptable to you...?Certainly. I know that Wedge's skins are currently not set up for RTL use at all... It may work. Then again it may not.Which is what was done after I requested to have $txt['reply'] disambiguated because it was used both as a verb and as a noun... :)It's not always going to be possible though, e.g. 'reply' is too short for that. :)Even THAT..?! Hmm...
I'm not convinced that performance-wise, it's a good idea to put into the DB whatever you're simply going to retrieve later without any sorting work... I mean, SMF/Wedge has the settings table to load entirely, but even that is cached to file, as you kindly reminded me a few days ago... :lol:

Something else... MoveTopic.php does, in a few occasions, load the default language for a file, just to retrieve a string in particular, and then reverts to the user's preference.
However, it 'simply' reloads the file without a second thought about the static cache.
I think it should reload by doing loadLanguage('File', '', false, true) (i.e. $force_reload = true and $fatal = false), don't you agree?

:edit: Forget what I said -- since it stores the latest language loaded in the static cache, then it will automatically continue loading the file. :)

BTW-- index.english.php went from 32KB to 27KB in size... And I'm not even finished!
An incredible amount of data really shouldn't have been in there in the first place ;)

Yes, please! That's how it should've been done in SMF, too. (I like how PHP 5.4 will allow you to write loadLanguage(['index', 'Errors']), too.)

Committed that today :)
How do you like all the changes?
Hopefully I didn't break anything... I changed so many things...

Oh, and I'm not sure about the short notation... Not because I don't like it, but because I don't see anyone using a PHP 5.4-only feature (that otherwise will break a site) in generic software (i.e. not stuff you write for yourself) for many years...

Haven't had time to look into things at all, sorry. It's on my to do list ...