User talk:LpSamuelm

From Bulbapedia, the community-driven Pokémon encyclopedia.
Revision as of 20:36, 15 April 2017 by LpSamuelm (talk | contribs) (-> Japanese holdovers)
Jump to navigationJump to search

Welcome

Bulbapedia logo.png
Welcome to Bulbapedia, LpSamuelm!

Here are a few links to help you get started:

The Manual of Style, or MoS, outlines the format of all pages on Bulbapedia.

Our friendly team of staff are here to help! Talk to them if you have any questions or problems with Bulbapedia.

On talk pages, please sign your comments with four tildes (~~~~), or by using the "Your signature with a timestamp" (button_sig.png) button at the top of the edit window.

On Bulbapedia, the ability to edit personal userpages is a privilege. Per our userpage policy, this must be earned by first making constructive edits to the mainspace. Once you can, remember to keep userspace edits (edits to User:LpSamuelm) to a minimum.

For a complete list of policies and editing advice, please see the Welcome Portal.
 Thank you, and have a good time editing here!
  «ιɴмɴιαc» 10:57, 6 June 2010 (UTC)  
 

Monospace/Gen II save data

Do you actually have some "real" reason the tables under checksum shouldn't have the whole cells in monospace? Is there a actually some significant problem with "to" being in the same font? It's the easiest solution; it looks fine. I get that your intention is to put the font on the hex values, but I don't know any reason why it's so terrible that "to" be in the same font. In other cases, I'd be happy to leave "to" out; and that's possible here, but doing it is just more trouble than it's worth (AFAIK). Tiddlywinks (talk) 21:07, 19 April 2016 (UTC)

Well, the reason they're in monospace at all is to set the hex values apart. tags are for just that - setting apart code. Having the entire sentence (which "[x] to [y]" is) in monospace makes it seem like it was taken straight from a .txt. Honestly I would've kept the tags even in the code-only cells in order to keep the formatting uniform, but it doesn't really matter as much there. So basically, to separate text content and code content.
Another formatting that would work, I suppose, would be to split the table up into a table with a "from" column and a "to" column - that'd be fine too, as the code and text would be separated in style in that case too. LpSamuelm (talk) 21:19, 19 April 2016 (UTC)
In lots of text, it's certainly worth setting apart the hex values. But in those tables, it's not (at all) hard to identify the relevant values, even with "to" in the same font. Can I ask you to just do something so that the code tags aren't used in the table? Either setting the whole row monospace again, or making from/to columns, or something. (Honestly, I tried from/to columns before and didn't like it. But...) I'll leave it to you, but those code tag formats are just too out of place in a table.
(P.S. If you removed the welcome template on purpose: please don't.) Tiddlywinks (talk) 21:26, 19 April 2016 (UTC)
I really liked code tags in the table, at least. Felt consistent, and was pretty enough. But sure, if it makes you happy it can't be that bad. LpSamuelm (talk) 21:32, 19 April 2016 (UTC)

Japanese holdovers

There's one thing I'm particularly confused about in your recent edit to Character encoding in Generation III. It's the bolded part below.

Characters on a dark gray background are, in all versions, unused holdovers from the Japanese encoding. They are displayed differently across versions.

It seems to contradict the "in all versions" part. Or are you talking about some sort of trivial differences somehow?

Tiddlywinks (talk) 18:54, 15 April 2017 (UTC)

Ah, no, both statements are true. They are unused in all versions, but display as spaces in FireRed, LeafGreen, and Emerald. Perhaps I should change that to something along the lines of:
Characters on a dark gray background are unused in all versions. In Ruby and Sapphire, they are holdovers from the Japanese character set, while in Emerald, FireRed, and LeafGreen they (with the exception of 0xAF) simply contain spaces.
How about that? I'd have to do some editing in the beginning of the "Revisional differences", but the added clarity might be worth it. LpSamuelm (talk) 19:34, 15 April 2017 (UTC)
I'm doing some moderate changes already anyway. I'll make sure it's accounted for. Tiddlywinks (talk) 20:26, 15 April 2017 (UTC)
I figured you would! I'll swing past once you're done and make sure you didn't change anything for the worse.