You can just use --first-parent to skip past commits in merged branches. Squash merges complicate stacked PRs.

But I agree on not rebasing PRs. Another benefit to avoiding force merges is that it's easier for reviewers to compare changes since their last review.

It doesn't seem like a pleasant, bilateral collaboration since Russian developers do not seem pleased about the Euro-Office initiative.[0]

[0]: https://github.com/ONLYOFFICE#%EF%B8%8F-legal-note

Yes, but they can't do anything about it anyway. The FSF resolution on this matter, though, essentially means that they might just as well pull Euro-Office patches into OnlyOffice. So in the end, the product will be formed by combined effort.

The codebase will diverge quickly; the Russian one is heavily obfuscated with s ton of Russian in it and obscure commit messages. A large portion of prep work by Nextcloud was cleaning and translating. OnlyOffice was also known for refusing PRs, too.

> Pursuant to Section 7 of AGPLv3, the copyright holder is expressly entitled to impose additional conditions. In the case of ONLYOFFICE, such conditions include, in particular:

>the obligation to retain the original product logo (Section 7(b));

>the denial of any rights to use the copyright holder’s trademarks (Section 7(e)).

In other words you must use our logo and you must not use our logo. Good luck enforcing that.

It's interesting that it renders Chinese in a TUI. I wonder if that breaks anything that assumes a character is always a column wide.

Terminals and things that live in terminals have relied on wcwidth() to handle this since time immemorial (which is always fun when they are out of sync, e. g. remote over ssh, but in the vast majority of the cases it just works).

Language support was probably an afterthought since their target audience all read Chinese

It feels quite choppy on mobile, but I think it could be fixed by adding touch-action: none

Fixed!

This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins.

If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.

Thanks for the tip. That does make sense, although I do think having your default CSS-defined font sizes (across your whole app, not just the main content) be a reasonable size should be the first priority.

Also, not having ridiculously oversized margins, like so many 2019-2022 websites trying to look "modern" used to use.

old.reddit.com is one example where the paddings still look good when magnification is set to 150-170% (which I have to do because of the tiny default font size). I think doing it that way but with better readability at 100% zoom, would be a decent solution.

This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?

Thanks for helping me realize my accidental anti-pattern. Can you link some of the sites that do that the worst.

I want to use those as references to fix my UI (on increased font-sizes on small screens) before releasing an app I've spent 4+ months on.

Perfect example for you: indeed.com (desktop site). unless its been fixed recently, huge swaths of area are already empty padded space, made worse by zooming

It's not that it's unreliable, it's just lazy research. Wikipedia, like all encyclopedias, is a tertiary source, but ideally your essay should be a mix of primary and secondary sources, while Wikipedia discourages original research and prefers only secondary sources. Wikipedia itself recommends against citing it as research[0] for this reason.

[0]: https://en.wikipedia.org/wiki/Wikipedia:Citing_Wikipedia

Laziness should never be the issue.

The issue is that Wikipedia can be wrong and you’d only know that by going to the source (or lack thereof), or checking other sources.

All secondary sources can be just as wrong, while standards of course might differ being published doesn't prove much on its own. Also of course in many/most non theoretical fields you find plenty of conflicting sources so relying on a "consensus" based high quality encyclopaedia article seems like a more reliable approach if you are new to the field and don't really understand what you are reading.

Wikipedia and text bots are unreliable sources for the exact same reason---they are anonymous. The point of a citation is stating that "I know this because X told me". The validity of that argument entirely depends on the authority and reputational harm X would suffer for being wrong.

The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.

[0]: https://github.blog/changelog/2025-05-05-improvements-to-cha...

UTF-8 is not locale independent. You cannot correctly render multilingual UTF-8 text without also specifying its locale, and some transformations like uppercase/lowercase also depend on the locale.

Eg: some cjk characters render differently based on whether mainland China, Taiwan, or Japan. One example 骨 (from my old notes so tiny chance this example is incorrect)

Yeah, 骨 is one but IMHO the best example is 返 -- it renders differently in every CJK locale.

> You cannot correctly render multilingual UTF-8 text without also specifying its locale

You can render it pretty well, not perfect, but good enough to actually read it, as opposed to not being able to render it at all or rendering mojibake à la Кракозябры instead.

At least touching Unicode strings in wrong locales only mildly corrupts the strings. Plenty of Win32 apps would crash if the system locale is in UTF-8.

UTF-8 is a character encoding and therefore it cannot serve as a locale. There is no UTF-8 language, punctuation, date and number formats…

I mean, UTF-8 string handling is language (of the given bitstream, not necessarily the system) dependent, e.g. Turkish lowercase I, Chinese Hanzi vs Japanese Kanji at same codepoints, etc etc...

> UTF-8 is not locale independent.

The encoding itself is locale-independent. Some algorithms (rendering, casing, hyphenation etc.) depend on the locale.

This is unlike the older paradigm, where the encoding itself was dependent on the locale, making things like copy-paste between applications running in different locales problematic.

You can serialize a BigInt by specifying a replacer:

    const obj = { a: 9007199254740993n }
    JSON.stringify(obj, (_key, value) => typeof value === 'bigint' ? JSON.rawJSON(value.toString()) : value)

And then you end up with strings on the other side, not numbers.

No you don't? The example I gave produces

    {"a":9007199254740993}

not

    {"a":"9007199254740993"}

Oh, that's much worse! The JSON string `{"a":9007199254740993}` decodes to the object `{"a":9007199254740992}` with typical JSON parsers like JavaScript's `JSON.parse`.

If you're applying a replacer, then you'd supply a reviver when parsing:

    const json = '{ "a": 9007199254740993 }'
    JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)

Yeah but now you have the world's biggest foot gun in your API.