Help talk:Temporary accounts/Archive 1

Please fix translation markup

Hello. Could you please defragmentise the translation tags/units existing in this document? There translation units are excesively fragmented, which makes translation harder by not having full context of the whole thing to translate. See m:i18n for best practices. Thanks! —MarcoAurelio (talk) 14:20, 1 October 2023 (UTC)

@Shirayuki has been doing this fragmentation on many pages for a long time, calling it "simplify translation units", but actually, it does more harm than good. Putting every sentence in a translation unit overloads paragraphs with translation markup.

It does make sense to make translation units shorter, but the right way to achieve is to make the paragraphs in the source text shorter in the first place. A paragraph of more than five sentences is hard to read in any language in a technical document, even before talking about translation. A paragraph of five sentences or fewer is easier to both read and translate.

@Shirayuki, please stop putting <translate> tags in the middle of paragraphs. It's really disruptive and no one else is doing it. Amir E. Aharoni {{🌎🌍🌏}} 17:17, 5 October 2023 (UTC)

Documentation pages on MediaWiki.org are frequently updated. Whenever the original text of a translated unit with multiple sentences changes, it becomes harder to reflect those changes in existing translations compared to simple translation units.

Longer translation units result in a higher number of translation variables ($1, $2, etc.). Translating longer texts all at once is also challenging, which decreases the likelihood of translations being made or changes in the original text being reflected.

Shorter translation units increase the chances of matching the translation memory. Shirayuki (talk) 22:52, 5 October 2023 (UTC)

Translating longer texts all at once is indeed challenging, but the solution for that is not to put every single sentence in a <translate> tag. The solution is to use shorter paragraphs. Ten sentences are hard to translate (and to read!), but five sentences are not much harder to translate than one.

Editing translatable pages with a lot of markup may seem easy to you because you do it so much, but it is hard for almost everyone else. Please don't make it even harder by putting a lot of <translate> tags inside each paragraph. Amir E. Aharoni {{🌎🌍🌏}} 14:15, 6 October 2023 (UTC)

I agree with Amir here. So far, the paragraphs and sections for the subject page are short and simple enough IMHO so that there should be no need to create additional translation units than those that Translate would create for every paragraph (except for bullet points, which is probably good idea to always split anyways). I don't doubt the good intentions, but excesively short translation units make translations harder due to lack of context, and makes maintenance of the subject page extremely complicated as well, because of the repeat unneeded markup and translation tags. —MarcoAurelio (talk) 20:37, 6 October 2023 (UTC)

Hey @MarcoAurelio, @Shirayuki, and @Amire80. This is a very interesting conversation, there are different arguments, and the topic goes beyond this page. I'm sure more people would like to join (for example, colleagues from my team) and certainly, even more people would be impacted if we changed any practice. Let's maybe move the discussion somewhere else? Preferably, Meta-Wiki, because that's the larger platform, and good practices should be aligned.

On a side note, as much as I don't believe in translating single sentences, not when I have good machine translation on the other tab/window and I start off with getting the entire page translated at once anyway, maintenance does seem to be easier. Also, I've had both complaints from translators frustrated that the paragraphs marked for translation were too long, and that single sentences didn't allow them to understand the context. This also varies by language. That's all fair. We need to find a middle ground, and I'd like us not to do that just here. SGrabarczuk (WMF) (talk) 16:34, 6 October 2023 (UTC)

Temporary user / username / account

@SGrabarczuk (WMF) started a discussion in the Hebrew Wikipedia about this feature and linked to this page. The discussion is constructive and interesting. One of the issues that came up there is how to translate the word temporary. I have translated most of the messages related to this feature into Hebrew, and I have consistently used a direct translation of "temporary" using a common Hebrew word with the same literal meaning. It's usable, but some people proposed to use another word, which means something like "that can disappear", "that can go away" (famously, it's used in the Hebrew translation of Gone With the Wind). Both options are fine with me, and we'll discuss and figure out something consistent.

However, that raised an even more fundamental discussion: What is the thing that is temporary? The user, the username, or the account? It's not quite the user, because that can be understood literally as the person who uses the site. It's true that in practice, "user" is often a synonym for "account"; nevertheless, precision won't hurt. The right thing to describe as "temporary" is probably the username or the account. As far as I can see, the messages in core MediaWiki and extensions used by Wikimedia say "temporary user", "temporary account", "temporary username" (or "user name"; I've just suggested changing one to "username").

Unless there's a specific reason to use "user", "username", or "account" in different messages, I recommend using one consistent word for this in all the messages, and it should be "temporary username" or "temporary account". The term "temporary user" should probably be discarded. Amir E. Aharoni {{🌎🌍🌏}} 17:35, 5 October 2023 (UTC)

Thanks @Amire80, yes, I think you're right, "temporary user" and "temporary username" should be replaced with "temporary account". It's not about the person and it's not about the name (which is actually more permanent than the usernames of the permanent accounts :D because one temporary account has only one name). So it's precisely about the account itself. SGrabarczuk (WMF) (talk) 18:35, 5 October 2023 (UTC)

Note on languages which distinguish gender: “user” might be male and is a human being, but “account” is neutral and an administrative term. Greetings --PerfektesChaos (talk) 09:03, 15 August 2024 (UTC)

transclusion problem with #lsth on translated pages

no transclusion observed on pages /xx , why ? ->

{{#lsth:Trust and Safety Product/Temporary Accounts/FAQ{{#translation:}}|What does a temporary username look like?}}

--Christian 🇫🇷 FR (talk) 13:28, 8 April 2024 (UTC)

FAQ for developers

A temporary account is in the user table, and is for all intents and purposes a regular account, but with a few differences

So my tool's intent and purpose is to save preferences for temporary accounts. Is it supported? It seems not? Not "for all intents and purposes" then.
It's not in the list of differences either. JWBTH (talk) 17:15, 10 April 2024 (UTC)

@JWBTH How is your tool currently saving preferences for temporary accounts? Can you please elaborate? Thanks. NKohli (WMF) (talk) 13:01, 11 April 2024 (UTC)

I assume it is not, because I see "temporary users don’t have preferences" in other place on the page. Convenient Discussions saves user settings when the user visits a talk page, along with a few other types of data, in user options prefixed with userjs- (see API:Options). See commons:User:Jack who built the house/Convenient Discussions#Data. JWBTH (talk) 14:25, 11 April 2024 (UTC)

Just to confirm, temporary accounts do not have the ability to save preferences. KHarlan (WMF) (talk) 16:51, 17 August 2024 (UTC)

Database backup dump changes

How are database dumps going to indicate temporary users? In particular wikidatawiki stub-meta-history.xml. Currently the contributor element has an ip= attribute for ip users. Bamyers99 (talk) 00:01, 16 April 2024 (UTC)

Hi @Bamyers99, we are discussing this in task T365693. Could we continue the discussion there? KHarlan (WMF) (talk) 16:47, 17 August 2024 (UTC)

Confusion how to identify unregistered accounts by JavaScript

Please see phab:T369803.

• If I want to avoid pointless guidance “Please modify your Special:Preferences” I do need to distinguish between really registered clients and no manual login.
• Is every read-only client a temporary user even if never attempted to edit? Or is the username null kept in the long run for 99,999 % of access just viewing articles?
• On which occasion the temporary username wil be stored as cookie etc.?
• How to implement in transition period?

PerfektesChaos (talk) 09:14, 15 August 2024 (UTC)

I would use mw.config.get( 'wgUserIsTemp' ) for client side code that wants to check if the active user is a temporary account.

This will return true only after a not-logged-in user attempts to edit.

If you haven't done so already, it might be helpful for you to try out some edits as an anonymous user on test.wikipedia.org to see what this looks like in practice. KHarlan (WMF) (talk) 16:53, 17 August 2024 (UTC)