The translations are edited in translatewiki.net (TWN). Here is a link to one language.[1] You can change the language with the link after "Translate to" in the upper right.
More info about TWN is in [2]. You can sign up on the main page[3] to become a translator.

[1] https://translatewiki.net/w/i.php?title=Special:Translate&group=out-wikimedia-mobile-wikipedia-android-strings&language=nb&filter=&action=translate&optional=1
[2] https://translatewiki.net/wiki/Translating:WikimediaMobile
[3] https://translatewiki.net

I hit this once as well.

In T75086#764869, @bearND wrote:

The translations are edited in translatewiki.net (TWN). Here is a link to one language.[1] You can change the language with the link after "Translate to" in the upper right.
More info about TWN is in [2]. You can sign up on the main page[3] to become a translator.

[1] https://translatewiki.net/w/i.php?title=Special:Translate&group=out-wikimedia-mobile-wikipedia-android-strings&language=nb&filter=&action=translate&optional=1
[2] https://translatewiki.net/wiki/Translating:WikimediaMobile
[3] https://translatewiki.net

Yeah, I'm aware of where they are translated, the problem is just that the messages have been translated since at least last July, but still haven't appeared in the app.

Also, the problem described in this bug (being logged in but editing from IP) still persists, I just tested: https://no.wikipedia.org/w/index.php?title=Det_kinesiske_tributtsystemet&diff=13735712&oldid=13733629

Correction: I hadn't tried the number one solution, which is logging out and logging back in (The IT Crowd is never wrong!), so here it worked as normal: https://no.wikipedia.org/w/index.php?title=Det_kinesiske_tributtsystemet&diff=13735718&oldid=13735713

However, the problem of the app showing me as logged in when I'm not really is still something that should be looked into.

Yes, I suspect the edit token expired after a while. I agree that this definitely should be looked at.

Regarding translations: I'm attaching a screenshot

In T75086#1095929, @bearND wrote:

Which translation are you talking about? So, if there is something missing please let me know which language/ which string is missing.

Yeah, those in the screenshot look right to me too. The only things I've seen that aren't translated are the pre-set edit summaries ("Fixed typo", "Fixed grammar", "Added links" and "Other"). Everything else looks fine. :-)

One approach is to use https://www.mediawiki.org/wiki/API:Assert . If the app thinks it's logged in (I don't recall if anonymous editing is currently supported), use assert=user .

The API will then fail the edit if the user is not logged in. You can then attempt to re-log them in if you still have the credentials, and re-prompt if the credentials are no longer valid.

Have discussed with @Ragesoss, marking this as private was an accident. There's nothing exploitable here.

Hi All - It would be great if we could prioritize this bug a little more. It has privacy and Creative Commons licensing implications. Please ping me if you would like to discuss further.

@bd808 will see if someone more familiar with the edit API can help us debug this. It may be that we're doing something stupid and we're just not aware of it.

Add assert=user to edit requests from users who are supposed to be logged in? That would fail the edit, but at least not make it not logged in silently. And if you add handling for assertion fails, you can at least have some debugging information.

In T75086#1147146, @MaxSem wrote:

Add assert=user to edit requests from users who are supposed to be logged in? That would fail the edit, but at least not make it not logged in silently. And if you add handling for assertion fails, you can at least have some debugging information.

I would rather fix the actual problem so that users do not have to sign in again. We can use assert=user if we can't do that.

My guess is that people are logging out on desktop and that the app is not noticing the session is now invalid. Easiest thing to do, which the app should do regardless, is pass assert=user; it's designed for this exact purpose.

You can also check if the token you're getting back is equal to "+\", which means you're logged out. Or you can make a request like https://en.wikipedia.org/w/api.php?action=query&meta=tokens|userinfo to explicitly see who the server thinks you are.

In T75086#1147158, @Deskana wrote:

I would rather fix the actual problem so that users do not have to sign in again. We can use assert=user if we can't do that.

Setting assert=user is a good idea even if you do fix the cause of the logging out, since it will prevent accidental IP edits next time something happens too.

I can probably spare a few cycles on this during our unstructured sprint.

Sounds like this has enough definition for us to move on it now. Thanks everyone!

Can't reproduce :(
Here are the exact steps I'm taking:

1. Log in within the app
2. Log in on desktop
3. Go to a page in the app
4. Log out on desktop
5. Edit the page in the app
6. Save the edit

(I've also tried interchanging steps 4 and 5)

When the API request is made to save the edit, the server returns a "badtoken" error, which the app correctly handles by re-logging-in the user behind the scenes, then resubmitting the edit. The "badtoken" response is given regardless of whether I specify "assert=user".

@Legoktm @Krenair Is there another way I can test this behavior?

Are you testing in the production environment? Maybe it has something to do with CentralAuth?

I have a patch that implements assert=user, but it's still only theoretical, since I can't reproduce the issue myself:

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

Perhaps @Krenair or someone else with an Android device can check out the patch and try reproducing? (I can send an APK if necessary)

@Mattflaschen yep, production environment.

I think an important step is missing:

5. Wait for x hours/days. Not sure how long, but it'll take some time for the cookie to expire.

Never mind. Got your updates after I wrote my comment.

I tested my instructions again on 2.0-beta-2015-03-23. It definitely results in a logged out edit, and the app still thinks I'm logged in. Your #4 and #5 are the wrong way around @Dbrant.

https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=8188322 has feedback from an iOS app user complaining about the same thing

@Etonkovidova can you help us repro/check this?

I checked it with 2.0-alpha-2015-04-02.

My steps:

1. I logged to the apps with my credentials.
2. I did some editing - and saved them.
3. I logged in to desktop - and looked at the 'View history'

I checked, just in case, my edits made from desktop are saved with my login.

@Etonkovidova Good. I see it used the IP address. That means you can repro the issue with an apk from the master branch. Would you try to edit with the apk I sent you via email earlier?

Re-checked with 2.0-alpha-2015-04-13 - all edits are attributed to a logged in user.

I will check again tomorrow morning - to check the case of possible lost of user session data (as e.g. in VE).

Elena checked with the APK that I sent her, which had @Dbrant's patch in it. So I guess that fixes the problem.

Re-checked next day after the first edit.

All edits were saved with my user name and 'Tags: Mobile app edit, Mobile edit'.

Change 200567 had a related patch set uploaded (by BearND):
Avoid IP edits when user is logged

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

Change 200567 merged by jenkins-bot:
Avoid IP edits when user is logged in

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

@bearND, @Dbrant: In which version the patch for the android version will be released, already in 2015-04-23 or in the next release (btw. when is it?)? :)

@Florian The patch is included in the current production version (2015-04-23). Please let us know if you see this behavior again.

In T75086#1254592, @Dbrant wrote:

@Florian The patch is included in the current production version (2015-04-23). Please let us know if you see this behavior again.

Thanks for the info. One german user[1] reports this problem, but uses 2015-03-23 (that's why i'm asking here, so i can ask him, if he can update). I will report, if the problem is solved or not :)

[1] https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=8329218

@Fjalapeno why was the iOS project removed from this bug?

Ohoh, see https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=8407663 (it's in german).

I fact: The user added an answer to his own talk page and ~~~~ (to create the user's signature) wasn't resolved to the username, but to his actual IP adress :/

Version: Android App 2.0.102-r-2015-05-14