Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nao
7426
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 13th, 2011, 07:27 AM »
Agreed on everything.
7427
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 13th, 2011, 12:16 AM »
I'm not doing plugins for now and I certainly wouldn't suggest you spend more time on them. You have a life, too!
7428
Features / Re: New revs - Public comments
« on October 13th, 2011, 12:14 AM »
Btw context isn't globaled in the Who code. Error log. Fixed locally.
7429
Features / Re: New revs - Public comments
« on October 13th, 2011, 12:13 AM »
Ah yes. Entities.

As for replacing -- we have to do it before pretty urls are done (forgot that) so I'll have to move that code down the page.
7430
The Pub / [Archive] Re: Logo Madness
« on October 12th, 2011, 11:58 PM »
I really like the 'beak' logos on page 46...
Can't find a better one for now.
Here's something in between.
7431
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 12th, 2011, 11:42 PM »
Well I'm sure we'll find some..... :P
7432
Features / Re: New revs - Public comments
« on October 12th, 2011, 11:28 PM »
Quote from Arantor on October 12th, 2011, 10:50 PM
@Nao, that's why I suggested doing it with a <we> variable ;) it won't ever be used in posts directly.
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...)
Quote
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.
QueryString....?
7433
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 12th, 2011, 10:41 PM »
Yup... Because we didn't really improve it in any way so far, and I don't give a damn about protecting my template changes (month list in the sidebar etc), it's an excellent candidate for being BSD'd.

Heck, that would even be a good reason to release other scarcely customized areas as BSD plugins...
7434
Features / Re: New revs - Public comments
« on October 12th, 2011, 10:39 PM »
@stackmouse> I remember when I had to ask the SMF team for a $txt['reply_noun'] as opposed to just $txt['reply'] because they used the same string both as a verb and a noun ('reply number 1' / 'reply to this message'), even when most languages don't use the same word for both...
Quote from Arantor on October 12th, 2011, 09:33 PM
$scripturl is the special case, because it's used in a ton of strings as well as throughout the source.
Well, then we could consider doing that str_replace on the buffer yeah, I guess...
Posted: October 12th, 2011, 10:17 PM

Okay, did it... I'm a bit disappointed by the low number of replacements this saves us from doing. It's mostly stuff in the Who language files (determineAction)... But it's so fast to do (I think a hundredth of a millisecond), it's not worth worrying about -- especially since there'll ALWAYS be a {scripturl} to replace, given that they're being used in the main macros.
Posted: October 12th, 2011, 10:35 PM

Oh, and maybe we could also use that for the quote tag. If you look into install.sql, {{scripturl}} is being used, and then replaced in Subs-BBC.php with $scripturl.

And now I just realized a problem...
What if users actually type {scripturl} in their posts...?!?!

(Good thing I committed this as a stand-alone commit, so that we can easily revert it...)
7435
Features / Re: New revs
« on October 12th, 2011, 10:34 PM »
rev 1103
(8 files, 12kb)

* Replaced individual {scripturl} replacements with a page-wide buffer replacement. It only takes a few microseconds. (Load.php, ManageAttachments.php, Subs-Cache.php, Subs-Template.php, Who.php, index.template.php, ManageNews.template.php, ModerationCenter.template.php)
7436
The Pub / Re: English British support
« on October 12th, 2011, 10:15 PM »
Quote from Arantor on October 12th, 2011, 09:19 PM
Question. Let's say we have arbitrary language x, based on language y, neither of which is English. Do we load English, then y then x?
Recursive load yeah... Not very efficient :P Nested languages would require caching, definitely.
Quote
Caching is a tricky subject for languages. Caching into the cache folder in the usual fashion? If so, I'm not clear how it helps performance.
$txt = unserialize('...') is only 10% faster than the regular version on index.french.php. Although this is about 50% faster:

Code: [Select]
$txt += array(
  'lang_locale' => 'fr_FR',
  'lang_dictionary' => 'fr',
  'lang_spelling' => 'french',
  'lang_rtl' => false,
  'lang_capitalize_dates' => false,
  'number_format' => '1 234,00',
  'time_format' => '%e %B %Y à %H:%M',
  ...

Also, the file is smaller by about 5%.

Oh, and yeah, most of the time, this format could be used directly in Wedge, rather than used after caching the files...
But it's probably not really worth the hassle. On my local install, loading index.french.php, even when going through loadLanguage and its complicated setup (template_include etc), only takes a millisecond... versus half a millisecond for a simple include() on the var_export version.
Quote
Quote
(e.g. we just do a md5 of the contents, after removing comments and whitespace.)
No, we should store it as a version number in the file rather than rely on contents as unless we store changes in the DB, the language files should be considered volatile.
No no, I do mean having the version number in the file -- I just mean we should have a script, on our side, that will go through the language files and increase the version number inside the files if they're found to have been changed against our reference files (i.e. the previous version)...

Heck, we could have a similar script for all files, so we don't have to modify manually all of those @version strings...
Quote
Elsewhere I mentioned gathering a list of the languages in a manner that encourages loading the files themselves to get the language's own name from it. Putting the version number would be trivial to load at that point.
Agreed.
7437
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 12th, 2011, 09:43 PM »
Heck. We could release the plugin as bsd so that anyone can build on it...
7438
Features / Re: New revs
« on October 12th, 2011, 09:27 PM »
rev 1102
(11 files, 11kb)

! Long-standing SMF bug: finally got rid of these 'Last post by ... in ... on Today'. It's not proper English, it should use on_timeformat(). (MessageIndex.php, Subs-BoardIndex.php, index.language.php)

* More {string} optimizations. (Subs-Template.php, Subs.php, index.language.php, Help.language.php)

! Quick and temporary hack for fixing the default English time format when removing the year. (Subs.php)

- $_GET['in'] is already tested as valid, no need to re-test it. Also optimized the string modification. It's only used on two strings, is that really worth a_preg_replace...? (Help.php)

- Removed $txt['your_pms'] from the English version as well. (index.english.php)

! French version had an incorrect default time format. (index.french.php)

* Indenazi. (Boards.template.php, MessageIndex.template.php)
7439
Features / Re: New revs - Public comments
« on October 12th, 2011, 09:13 PM »
Quote from Arantor on October 12th, 2011, 04:36 PM
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.
I don't know... 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. Thus, calling a preg_replace on every page will probably eat more time than this, I'd think. Although a page-wide buffer could OTOH allow us to use {scripturl} directly in strings in the template, and thus save us from globalling it... Dunno, it could warrant some performance tests.
Quote
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.
According to Wikipedia, English isn't the only one, and Greece has strings for it (π.µ. and µ.µ.). In the Philippines, one of the local languages has 'sb' and 'sg'. Japanese has its own -- gozen/a.m. 午前 and gogo/p.m 午後, but they're shown before the hour, not after. Same for Chinese. Heck, IIRC Japanese even has additional words like 'deep night'...
http://en.wikipedia.org/wiki/12-hour_clock
I'd tend to say that it's up to the server to translate that to the current locale.
Quote
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.
I can only think of one solution... Introduce a $txt['time_format_this_year'], with the simplified time format, and use it accordingly in timeformat() when required.
I'll be working on that...
Quote
I'm surprised... I didn't remember anything about that. I've been on many, many Japanese forums. A large majority uses 2ch-derived crap. A small minority uses Western forum boards, mostly vBulletin IIRC. I have yet to see a single Japanese forum using SMF. And I do mean a forum in Japanese, maintained by Japanese people.
Quote
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.
Well, my knowledge of Japanese (not fluent but I can read it just fine) would definitely be helpful here, when it comes to modifying our code so that it helps the Japanese version feel more natural.
Quote
Internationalisation is an incredibly complex art,
...And normally the job of an internationalizer. But apparently, at SMF, that job consists in making sure that the various language packs are returned in time... It doesn't even require speaking English correctly. :P
I speak French and English. I have a good knowledge of Japanese and Spanish. I can read some Italian (well, didn't learn it, but it's not very hard for a French :P). That's all I can say about myself. I'm a bit old to be learning any other language ;) Oh yes, I read a bit of Chinese, too. But that's only because common traditional hanzi and kanji are identical... Wo bu shi zhongguoren.
Quote
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)
Hmm... I don't know any RTL language so I can't really speak on this matter.
Additionally, I haven't tested Wedge in RTL mode for a VERY long time... :-/
7440
The Pub / Re: English British support
« on October 12th, 2011, 08:46 PM »
Technical suggestion...

British.language.php or whatever:

$based_on = 'English';
$txt[..] = '...';
$txt[...] = '....';

Load.php:

if (!empty($based_on))
{
  $original_txt = $txt;
  loadLanguage($based_on);
  $txt = array_merge($txt, $original_txt);
}

(And even better -- cache the resulting language...)
Posted: October 12th, 2011, 08:41 PM
Quote from Arantor on October 11th, 2011, 04:01 PM
I can't see it disappearing either, in which case we might as well remove the internal disable option for it.
Sure...
Quote
Quote
add a version number to every single language file
That's not a bad idea. A little bit tricky to get right, but certainly doable.
It's just a bit annoying to maintain once we hit gold... :-/
Or we could have some sort of script that automatically updates the internal version numbers if it finds any difference against the previously stored file (e.g. we just do a md5 of the contents, after removing comments and whitespace.)
Quote
The variable nature before made it practically impossible to get this one right,
I can see it working, with a 'complex_string' function as I said...
For instance, function_exists('something') could be turned into {function_exists:something} and automatically modified by complex_string. Of course, the more choices, the slower it gets... But we can simply check for strpos($string, '{') before continuing. ({, or <we:, or whatever...)