Should be possible by passing

wfMessage( "january")

as an argument. PAtches welcomed!

@Jdlrobson It would work for most languages, but not for the ones where there are multiple grammatical cases (e.g. Polish). I don't see why is it worth showing only the month instead of the full date, for which we have tools to localize.

Change 341015 had a related patch set uploaded (by eddie):
[mediawiki/extensions/MobileFrontend] Localize registration date on user pages

https://gerrit.wikimedia.org/r/341015

Ping @Nirzar - see @EddieGP s comment above.

@Jdlrobson Arrgh, of course there shouldn't be the time shown. With "full date" I meant something like "18 March 2015", not "18:13, 18 March 2015" of course. Shame on me, I guess I did git add/commit/review from the wrong branch as I've experimented with various date functions before I found a solution that fits. -.- New patchset is up now, not using getHumanTimestamp (which returns date and time) but userDate (which returns the date only). Here's how it looks:

P.S: [offtopic] When pinging somebody within a sentence, remeber to add a space, so that it reads @EddieGP s and not @EddieGPs . How you did above didn't work ;)

Can we humanize this, is it easier to localize the words "months" and "Year"

I prefer "Member for 4 months" "Member for 6 years"

I've done that, though I think it's a bit hackish. There isn't really a function that gets the duration inexact (and doesn't show "5 years, 3 weeks, 2 days, 7 hours, 19 minutes, 25 seconds" but "5 years, 3 weeks"). Months aren't available though, as the function has no definition for them at all, I guess the one who implemented that didn't want to care about the question: What is a month? Is this 4 weeks=28 days or 30 days or 31 days?

We already have logic for this for the last modified bar to do this in JS:
M.require( 'mobile.startup/time' ).timeAgoDelta();

5 years, 3 weeks, 2 days, 7 hours, 19 minutes, 25 seconds would be shown as '5 years ago'

Reviewed in standup, decided to track in the sprint as part of normal workflow, but no estimate. :)

@Jdlrobson So your suggestion would be to use this logic and make php out of it, right? And, you're right, this logic would in fact be _much_ better than what I'm doing by now with this elseif-crap. I'm asuming you don't want me to use this directly (I *guess*) as processing statical content with JS isn't something that we're going to do.

Id suggest just doing a js enhancement on what youve already built. Consider a user who just joined. If it says a few minutes ago and gets cached for 10 days it will quickly go out of date. I think what you have minus the time is fine for users without JavaScript

Does this make sense?

Well I've now done what I thought you meant - and I think the code is better now, using a loop instead of a bunch of elseifs, even if that's not what you meant. ;) The logic within the js was just much better than mine. It also takes the hard-coded duration names & times away from the skins file and uses the existing definition in language class. This also enables the potential to add "months" as a valid duration unit in core, one would just need to add this to Language::$durationIntervals and define a dureation-months translation message. If somebody is interested in this, feel free to file a subtask. The userpage now shows "member since 3 weeks", "member since 6 years" etc., which is just fine I think.

A native English speaker should decide whether we should change the mobile-frontend-user-page-member-since message so that it's "member for" instead of "member since" once this was merged. AFAIK also "since" is valid but "for" fits better for durations. However, even if this is not changed, we should mark this message for re-translation as in foreign languages there may be a difference between showing the registration date and showing a duration.

@Jdlrobson This indeed does make sense, simply having my output as is now and giving a js manipulating this content to be up to date regardless of caching. I'll try to do this although I'm quite unfamiliar with js and especially mediawikis js structure, but I guess the 'last modified' bar does exactly the same thing (generate statical content, give a js that changes this - if js is available) for the same reason (caching). So it'll probably give me a hint how to do this. :)

Sweet!
Am excited to see what you come up with @EddieGP - completely understand about your unfamiliarity with JS - don't worry we'll here to guide and help you. Understanding the last modified bar should give you the information you need but please do reach out on this task or on the patch with any specific questions we can help you with!

@Nirzar with respect to the i18n what messages should we use? Would switching to "Joined" make sense here?
e.g.
"Joined 3 years ago" / "Joined 7 months ago" / "Joined this month" / "Joined today!"

"Joined 3 years ago" / "Joined 7 months ago" / "Joined this month" / "Joined today!"

Yes, also it can be approximate. the idea is to give a sense of if the user is Very new, somewhat old or a veteran of the system. 3 years 2 moths and 3 years 6 months doesn't really make a difference.

@Nirzar: The code is not doing this anymore. When you're longer then 1 week in, it shows the number of weeks and nothing more. When you're longer than one year in, it shows the number of years and nothing more. "3 years 2 months", "3 years 6 months", 3 years 9 months" and even "3 years, 11 months, 29 days" would all be the same, namely shown as "3 years".

@EddieGP
sounds good!

Can we fix the alignment while we are at it? the wrong alignment is a regression bug

I don't really know which alignment you're talking about, could you specify this a bit more? I assume alignment is meant in terms of style here?

@EddieGP Yes, the styling

1. the gap between subtitle and the actions is messed up
2. the icon is grey instead of blue
3. the links should be WMF blue color #3366cc

Thanks, I'm going to look into this as well, after finishing the js thing.

@EddieGP Thank you! That would be wonderful.

I've just uploaded patchset 8 which should do the js part. But I need some help here, the new system messages I defined (in en.json & qqq.json) somehow aren't shown correctly. Just the <this-message-does-not-exist> form is shown and I don't have a clue why. In addition this patch reuses a lot of code of the from the functionality to show the latest edit in a bar at the bottom of mobile view. Duplicated code maybe should be avoided somehow, some statement on this also would be appreciated. I'll leave a comment within the code at gerrit to show until where I could check my problem with the system message up.

Quick note: There aren't any changes for the style issues already, I wanted to deal with the js about the "joined" thing first.

I found a solution on my problem with the js now showing the message I defined (needed to add it to extension.json for resourceloader) . I'm now going to

• fix the style with the js solution (currently ' <div class="tagline">Member since 6 days</div>' is replaced by 'Joined 6 days ago', but the div is not added again, nor the class is kept. Need to figure out how to make jQuery add this, might not be that hard) done
• rewrite the php part of showing the date. For this, I needed to decide what output should be shown here. I could have used the same "joined 6 days ago" messages as with the js enhancement, but this may soon get out of date: We would again have the problem that when the user is registered for 15 seconds and the page gets cached for 10 days, viewing the userpage with js disabled would just show a "joined 15 seconds ago" message. Hence I would like to switch this back to userDate, which states "member since 15.02.2016" (localized of course). Also this would be consistent with the last-edited-bar, which's like " Last edited on 8 March 2017, at 19:38 " when js is disabled. Of course, unlike this bar, the time won't be shown on member-since. Please let me know if you have any differing opinion on what to show here (and I won't be annoyed about a quick note if you agree either ;) ). done
• look into the style issues mentioned above afterwards keeping this for a follow-up

The latest patch has a few issues:

(but seems from the recent comment from @EddieGP that they are on top of them :))

(Also updated previous comment).

The bug as outlined in the task description is fixed with the patch that's up now (at least as far as I can see, don't hesitate to point me to problems). I haven't fixed the style issues that @Nirzar pointed out though, as I think this patch is already big enough and it's better to split it up here, to fix the style problems within another follow-up patch. A follow-up is also required for generalization of the code (a lot of which is duplicated by now, as it is suitable both for the last edited and the joined bar. I'm going to work on this within the next days.

Makes sense to me @EddieGP. @Nirzar can you capture the issues you see in another patch so we don't lose sight of it?
Let's work on fixing the bug, generalising the code and merging both patches together!

@Jdlrobson I filed a subtask for this, I'm going to start it once this task is done (don't want to produce unnecessary merge conflicts). I think @Nirzar already outlined those issues at T150174#3086472. Are there any specific information you're lacking? I haven't looked into those issues already but I think the idea of what he meant was explained already.

Merging blocked until we've had time to reflect on the current approach (T160675 ) and generalise the approach if needed.

I maybe should have noted that I didn't start work to generalise this code due to @Jdlrobson s comment above. I'd be a waste of time to generalise this if it maybe will be dropped directly afterwards due to T160675 . So starting my work on generalization is blocked until we've decided to keep it this way or how to change it.

@EddieGP we had a chat about this in the standup and we've agreed to merge this in current form as it allows us to make this translateable and collect some translations. T160675 and/or generalisation is less urgent. Thanks for the contribution! :)

Change 341015 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend] Localize registration date on user pages

https://gerrit.wikimedia.org/r/341015

Tested on BetaCluster, looks ok, there is small flicker (when JS kicks in and overwrites the exact date to "... ago") but we can live with it for now (until we solve T160675)

@pmiazga - do you have some testing steps for this?