Else code text is adjoined to the vertical codebock border.
Also use explcitit "scroll" for odd browsers completely hiding the
scrollbar otherwise. One could argue "auto" still being more correct
since this matches what is evidently the desired and preferd styling
by those browser vendors. But on the other hand user confusion from
this questionable styling decision seems more problematic and already
occurred.
Commit 65201e3000 added the mfm class
(back) to MFM posts to adjust emoji sizing and commit
ebe4158885 changed codeblocks to respect
the original line breaks allowing to scroll the code container.
However, we still carry CSS to display legacy MFM representations
and one of the legacy rules matched on just the mfm class changing
display to inline-block.
This caused code blocks to not become scrollable, but simply overflow
while at the same time pushing the logical line length for all other
text in the statuses so it may overflow too. This overflow then got
truncated making the post unreadable.
Fix this by renaming the MFM post indicator class
to avoid any overlap. This may potentially leave legacy MFM broken,
but further research needed to figure out why it chooses inline-block
display in the first place.
Mostly-resolves: AkkomaGang/akkoma-fe#511
By default DOMPurify removes enclosing semantics and annotation
elements but retains their children by reparenting them.
This led to supposed to normally invisible source annotations
being rendered next to the proper math expression.
Fixes oversight in: d0135f4a71
Fixes: AkkomaGang/akkoma-fe#509
There is no issue on current backends and
this simply doesn’t make any sense.
It lead to sometimes remote accounts _never_ showing up in the suggestor
if they were not in the first page of results for just the local
username part of their handle unless the account was already loaded
into cache by some other means beforehand.
We don’t want to kick of a barrage of remote request on the backend
attempting to lookup half incomplete nicks. Nor do we, in the client,
want the additional latency of waiting for the backend to finish those
futile network requests.
Eventhough the suggestor used to call the API with an explicit
resolve=true, no actual WebFinger lookups should’ve ever been
made due to the suggestor (otherwise) nonsensically stopping
backend queries if there was a remote domain fragment.
(Yes, "emoji_input" also handles user suggestions)
Fixes oversight in 4d578720e8.
Avatar upload logic is wrapped in an explicit Promise object and
thus cannot access the tab’s this object. Instead it uses an
indirection via a captured local variable "that" for all existing uses,
but this was overlooked for the added bits.
All other uploads do not use a cropper and are not affected
Fixes: AkkomaGang/akkoma-fe#505
Using `--input` for codeblock backgrounds is not ideal, but the best we
can do with currently existing variables. Using colours not nominally
intended for text background risks borking on custom themes.
Among actual background colors we have
- the regular post background `--bg` which never provides distinction
- the background of _selected_ posts `--selectedPost` which
only offers a visual distinction for not selected posts
- Background of profile `--profileBg` which is only used in absence of
a profiel banner image — but Mastodon API requires us to _always_
have a banner image (so this color is not actually used and thus has
a higher chance of breakage)
- the background of input fields `--input`
The latter is well tested and almost certainly well legible
with a decent chance of creating a visual distinction.
Future patches to create a distinct new colour variable for codeblocks
and the plumbing in the theme editor welcome.
The old code was inconsistent about when the mention line state and
remembered spacing were reset as well as failing to add necessary
whitespace if a mention line was immediately succeeded by a plain text node.
The latter was kludgily fixd for a particular special case with the
last-child exception to whitespace trimming. (However this could en up
to retaining superfluous undesireable space in other cases)
This led to sometimes space being added "back" several times
notably leading to one extra, empty line in blockquote elements
succeeding mentions with whitespace. This stalled the otherwise
unrelated AkkomaGang/akkoma-fe#412
Now we always reset the mention chain and remembered spacing together
and also add back spacing in front of plain text nodes if appropriate
obsoleting the last-child exception.
Previously it was only adjusted for effects involving scaling,
creating odd inconsistencies betwen e.g. an unstyled emoji and
a slow "tada" animation as well as reduced compatibility.
To ensure scaling still works for posts with FEP-c16b-like HTML
without the source type being actually indiated as (vanilla) MFM,
the 2em rule specific to scaling tags is retained too.
Long'ish values and keys are not too uncommon and this lead
to them becoming unreadable, the full text only accessible as a tooltip.
Overly long single words are still ellipsised to prevent overflow.
Just like the old NIH HTML parser this test wrongfully assumed
">" couldn't appear unescaped in tag attributes and thus was
broken for many months now after a browser upgrade in our CI runners
caused this to be quoted automatically anyway.
Instead test against actual injection attempts
of additional styling rules and new attributes.
The backend is already supposed to sanitize everything for us
and it is rather restrictive even. But it’s simple enough,
so lets make sure of it and lessen the real-world impact
should there ever be backend sanitizer bugs (if at all,
then most likely in fast_html or its HTML parser dependency)
DOMPurify can only return a body element or a DOcumentFragment
not a full document as DOMParser does. However we only ever
grabbed the body object anyway so let’s just return that directly.
The inhouse parser wrongly assumed tag attributes could not contain
literal '>' characters, has issues like the recently fixed
AkkomaGang/akkoma-fe#480 and probably many
more problems. In any event the regex and characterwise parser mess was
hard to read and reason about.
Browsers already have optimised HTML parsers built in so use it.
Also rework the nested function into a parser class for even better
readability.
Other than using a proper HTML AST and rearranging everything into
a class this for the most part closely follows the previous logic.
More substantial logic changes were made to emoji processing and
green/cyantext styling.
The former now processes text in chunks to the next colon rather
than character by character. The latter is possibly a bit more
leient in what it styles now and no longer will break styling
tags enclosing a <br />.
The reverse pass basically only dealt with hastags and existed
to make detection of the "last" set of consecutive hashtags easier.
But since lastTags was never used and thus dropped in the preceding
commit, the whole pass is obsolete too.
We can simply parse hastags during the forward pass.
HTML tags can in fact contain '>' characters in quoted attribute values.
Besides that the regex replace failed to normalise whitespace
or to strip invisible elements. And lodash’s 'unescape' function
only replaces a limited set of quoted HTML entities, not all.
The computed localCollapseSubjectDefault was removed from status_content
about five years ago in 50aa379038. Ever
since this clause was effectively dead code but spamming Vue warnings.
It used to automatically reveal NSFW attachments already hidden behind
a collapsed content warning. However, this means it was impossible to
reveal just the text of a content warned post and we already have a
separate settings for always revealing NSFW media if desired, although
this admittedly will also reveal cw-less media directly.
Given there seemingly were zero complaints about the effective new
behaviour, let’s just drop the dead code conditional.
Ideally alt text and image would be handled together, but this is not
straightforward to do with the current profile tab and API interaction
setup.
To somewhat alleviate this, always submit the current matching alt text
too when uploading a new image. This allows an alt text edit before
confirming the upload to immediately take effect without the user
needing to remember to go back to the upper section to hit "save" there.
Only avatar alt text is integrated into the UI in an assistive way.
Header and backgrounds are set as CSS backgrounds and I don’t know
of a good way to add alt or aria-label attributes to that. Nor whether
it even makes sense to bake this into the default view since their just
decorative background elements.
The full al text can still be accessed through the new profile media gallery.
Despite many places setting distinct :title and :alt atttributes
for StillImage, it actually only had a :alt attribute used for both.
This is however not what we want here,
so add (back?) :title as a distinct property.
Related backend change: AkkomaGang/akkoma#1034
E.g. bridgy doesn’t federate the full MIME type and
it’s attachment URLs also have no extension. Thus
the full MIME type is always just a generic binary,
but since it still federates a more specific AP type
the generic Mastodon type still contains some information
we can use here to display it properly.
While at it, drop unused fileMatchesSomeType function.
Its last users disappeared in e654fead23.
Ref.: https://github.com/snarfed/bridgy-fed/issues/2198
Co-authored-by: Yonle <yonle@proton.me>
This used to cause null errors e.g. when initialising the accounts for a
newly created list, which also prevented a post-creation redirect to the
new list’s page from occuring.
Co-authored-by: Yonle <yonle@proton.me>
Fixes: AkkomaGang/akkoma-fe#367
Fixes: AkkomaGang/akkoma-fe#368
Mostly just reordering, whitespace changes
and removing superfluous "this".
eslint really wants us to add :key to the UserAvatar list in DM
conversation cards. With :key Vue will reorder elements instead
of patching their contents on list changes, allowing input state
of elements to be preserved. This doesn’t really seem relevant
here since USerAvatars do not have a state, but also not harmful.
One lint complaint about using double quotes at the outer level
was purposefully ignored as it results in needing to quote
double quotes within the string making it rather unreadable.
It was not easily available in the narrow "mobile" interface
until now since both the desktop_nav and top nav panel are hidden.
Placing bookmarks after lists is consistent with the top nav panel
(though the top nav panel also puts interactions before both).
The recently removed "direct" timeline was similarly unavailable,
but its replacement, dm conversations, was already added to the
side drawer upon its introduction.
Fixes: AkkomaGang/akkoma-fe#474
Thirty seconds is much quicker than any other auto-refreshes in the
interface. Emitting a request for every users and tab with the poll
loaded this frequently can add up to a noteworthy total on the backend.
This is significantly worsened by our backend currently synchronously
fetching and updating the status of remote polls when queried about
while initiating a remote fetch for every incoming request inbetween
the last refetch passing the age threshold and the first current fetch
suceeding and completing its db transaction.
In preparation to an eventual switch to native Masto API format,
as well as flexibility to backends without the extension,
the entity normaliser just copies the count paramter to the same path
The current user info fetcher will also be used for
total unread DM counts in the future.
To avoid any future mishaps with improperly stopped fetchers etc,
this does not use the existing 'setCurrentUser' method but a new
update method with a safeguard against accidentally changing the
identity.
This replaces the removed "direct" timeline.
Curtnetly this is a read-only interface missing ways to
mark conversations as read, dismiss/delete conversations
or modify the core members of a conversation.
Future work may also add QoL stuff like automatic implicit addressing of
core members or (provided another backend extension) add messages to a
conversation without replying to something particular.
It has been long deprecated and even already removed from Mastodon
and our existing implementation suffers from bugs (at least on
large/some instances), see:
AkkomaGang/akkoma#798
Except for pleroma-derived web frontends, other clients generally don't
seem to make use of this timeline either, often also omitting an
interface for the conversations API.
Even if it worked properly, this isn’t the best way to present
DMs as all threads with different participants or topics are mixed
together in one linear timeline. The conversations API which suceeded
it in Mastodon and our backend already supports offers a much better
interface.
Fixes regression in f2c55423fd.
Ideally, this would only set state for what was actually changed
rather than rewriting the entire storage each time, which would also
have avoided this issue.
The fix is somehwat hacky not working with an empty path list or
parsed/internal fields not at the top-level of a path, but in practice
this seems to be always called with well bheaving paths. Should this ever
become an issue, this should migrating to the overall saner updating
approach described in the preceding paragraph.
Note: the cloneDeep call was originally added in
a97c07bfdf as part of
https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1385
Though it is not clear why setState would mangle its data argument
as it supposedly does to necessitate this copying.
As of Node 25, corepack will no longer be included by default in
the distribution:
https://github.com/nodejs/TSC/pull/1697
A separate corepack package is already available in npm, which
should work the same as the corepack that was included in Node 24
and prior.
The rest of the build instructions should remain the same.
This makes any filter that starts and ends in forward slashes act as a
regex filter instead of a simple substring filter.
In case any existing plain-text rule already matches this
it will need to be updated adding an additional layer of slashes
and escapes as needed. However, this is thought to be sufficiently uncommon.
Instead of using trailing flags as modifier complicating parsing further,
any modifications to regex matching must be done via local modifiers. See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Modifier
Visibility scopes have no total order, but the function signature
of a compare function implies/requires such.
This led to the scope selector showing "local" as a possible option
on some original post scopes it was not actually compatible with.
The negotiated initially selected value was already correct though.
Was noticeable by e.g. the scrollbar being shown somewhere inside the
container and not being able to scroll near the edges if each line of
text was sufficiently short.
Directly implements the suggesstion from
AkkomaGang/akkoma-fe#456 (comment)
The upload call hid errors and the entity normaliser lets them pass
through as well (assuming it must be an already "correctly" formatted
legacy qvitter response), which led to errors being added to the the
draft as if it was a valid attachment object.
On later use of this error exceptions occur breaking the frontend and
due to being saved as part of a draft this could only be recovered by
clearing local client data.
Fixes: AkkomaGang/akkoma-fe#339
This is the canonical reference to a post and works best for lookups on
other servers. Previously this canonical ID was not accessible from the
frontend at all.
The "source" button continues to redirect to the preferred display URL
though (if set), since this is as the name suggests the preferred URL
for viewing the post in a browser (it might however not work when the
source instance restricts unauthenticated access even to local content).
This lifts the redundancy between the "source" and "copy link" buttons.
Since the legac qvitter API is still accounted for in the entity
normaliser, we just assume its external_url serves as both the canoncial
location and preferred display URL. It is dubious however, if this
codepath can even still be triggered at all and it likely makes more
sense to purge all remnants of the legacy API from the codebase.
Resolves: AkkomaGang/akkoma-fe#166
This reverts commit e1b4d8f59a
and obsoletes commit c2db0e66ef
which already unset min-height in notifications where this
caused images to become effectively invisible.
Image previews are currently designed to always show the full image
scaled down as needed. With min-height though they were allowed to
take the full width even if it caused overflows in vertical direction.
This happened to look kind of fine with only easy-to-miss overflows
in the main post view if each preview row had the same amount of
columns, but creates jarring overlaps otherwise.
Fixes: AkkomaGang/akkoma-fe#456
The media modal was changed to use still_image, but the attribute
pointing to the image load event handler wasn't updated.
This causes the modal to remain in the loading state forever.
Fixes: f48138c979
Instead, just also prefill the text wuth the user handle
for pure mentions.
This lead to us sending a boolean status id to the backend
which presumably only didn't cause problems in *oma backends
because API spec validation dropped the value with a mismatched type.
On an Iceshrimp.NET backend this caused errors to pop up.
There are more conditions gated by replyTo in the post form but
no longer triggering them doesn't seem to have any noticeable effect.
The one noticeable change being mentions now share a draft save slot
with regular message composing (before all mention messages shared the
same reply:true slot), but this seems sensible enough.
At least modern versions of corepack'ed yarn
(as build instructions tell use to use)
reaaally want to add this to the lockfile,
so let it do so to not need to constantly
be wary of uncommited changes here.
We don’t need them after initial account registration
and they just clutter the database otherwise
Together with the preceding commit this should get the
flood of garbage tokens into our database under control.
(We still want to fix the backends cleanup of old,
already existing tokens though)
Fixes: AkkomaGang/akkoma-fe#429
Original commit amended with a fix for registrations;
they need to (now) create an app and fetch an app-only token
before doing anything else, as this endpoint requires such a token.
Co-authored-by: Oneric <oneric@onierc.stub>
Cherry-picked-from: 0e25b94186
This only worked in *oma due to legacy session-cookie auth kicking in
(which we should really get around to fully purge).
Cherry-picked-from: e8896fad15
The frontend assumes these URLs will be relative to the target instance,
which may not be the case for non-*oma backends like Iceshrimp.NET
due to the backend storing emoji in an external object storage depending
on configuration.
Cherry-picked-from: c147c2aeb3
If I'm replying to a post in Klingon, chances are I'm going to write in
Klingon. This reduces friction for properly marking post language in a
conversation.
This fixes random actions being triggered by the enter key while the
subject field is focused.
When pressing enter, the browser simulates a click on the first "submit"
button it finds in the form.
A submit button is a button without `type="button"` set.
Remediate this by setting the type attribute on all but the "Post"
button.
Additionally, inhibit the enter key in the subject field (ctrl+enter
still works).
Currently translated at 72.0% (758 of 1052 strings)
Co-authored-by: Deleted User <noreply+21@weblate.org>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ja_EASY/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1052 of 1052 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1051 of 1051 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 19.6% (207 of 1051 strings)
Co-authored-by: Hasan Yıldız <hasanyildiz0@yaani.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/tr/
Translation: Pleroma fe/pleroma-fe
This allows discerning how many voters agreed
with an option and aligns with other clients.
However, a backend bug makes this impossible for
remote multiple choice polls, so retain current
behaviour for anything affected.
In a status, we can choose to translate the status (assuming there's a translator enabled on the backend)
It will translate, in practice generally according to detected language, and also provide an option to override the source language.
Translating can take a while, and there wasn't really a visual feedback when it was translating.
Now the translate button will be dissabled while translating.
The code to turn mdm-data-* attributes into a value for the style attribute is complex.
I wrapped it in it's own function now for better code readability.
A comment was already provided with what the code intents to do and why, this information has also been moved
to this function.
Currently translated at 99.7% (1046 of 1049 strings)
Translated using Weblate (Polish)
Currently translated at 99.7% (1046 of 1049 strings)
Co-authored-by: ? <akkoma@mkljczk.pl>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: subtype <subtype@hollow.capital>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/pl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 8.1% (86 of 1049 strings)
Translated using Weblate (Lithuanian)
Currently translated at 5.5% (58 of 1049 strings)
Translated using Weblate (Lithuanian)
Currently translated at 1.9% (20 of 1049 strings)
Added translation using Weblate (Lithuanian)
Co-authored-by: Vaclovas Intas <Gateway_31@protonmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/lt/
Translation: Pleroma fe/pleroma-fe
During code review a much better way was pointed out to do the emoji scaling, by using `em`.
*key uses 2em for emoji, which is smaller than Akkoma has. I now kept the 38px for Akkoma,
but when "zoom" (ie x2, x3, x4, tada) happens, we set to 2em and zoom from there.
This fixes drafts not clearing after posting a reply.
Vue 3.3.11 changed watchers to stop firing after component unmount.
After posting a reply, the post form is removed, now causing the queued
event to be discarded.
Synchronous flush causes the handler to be called immediately when
changes happen, solving the problem.
The performance impact of this change seems non-existent. Even before,
typing would generate an event for each keystroke. Pasting is atomic.
See: https://github.com/vuejs/core/pull/7181
See: 80e2128d52
Fixes: a7dea2f70fFixes: #413
For some strange reason, after a mention a quote would be double as high as it should.
Removing this "pre-wrap" seems to fix this. I'm not sure what it was exactly for, but I don't see anything break.
The code blocks now don't wrap any more, but show a scroll bar, which imo is better for a code block.
Blockquotes are blocks, so not wrapped in an extra p-tag.
In statusses this gave an unfortunate result that the margins were different.
A p-tag has a bottom margin of 1em. Blockquotes had 0.2em top and bottom.
So under a paragraph there was 1em space, but under the blockquote, there was only 0.2em space.
The last p-tag has 0 margin at the bottom.
This commit basically does the same thing for blockquotes now, making it more consistent.
One difference is that the blockquote has a left margin of 0.2em because a little "jump"
in makes it look a bit better imo.
In code review it was decided that faint text for blockquotes should be used.
I copied how it was done in other places to faint text.
When making a theme for *oma-fe, there's a check for how readable things remain.
I'm unsure how that exactly works, but timestamps for a status is also faint,
so by using the same way of doing this, this should also be taken into account
for the theming engine.
An instance may restrict access to the public timeline (among others)
to authenticated users and there already is a setting to decide which page
to show authenticated and unauthenticated viewers by default each.
However, the logout redirect didn't honour this setting
leading to potentially broken pages and errors on logout
Previously quoted text (e.g. in Markdown `> Some text`) was italic
When two different quotes were made, there was no destinction between the two, making it look like one quote
This is confusing
Now we have a vertical line in front of the quote
When two different pieces of text are quoted, it is now clear because the lines are separated
This vertical line is a typical way of visualising quoted text, so it should be easy to understand what it is
For colour in MFM attributes, we expected a `#`, but that's apparently wrong. The BE
translates the `color` attribute in `$[fg.color=000 text]` into `data-mfm-color=000`.
But for the SCSS to work, we need to put it in the style attribute as `--mfm-color: #000`.
Generally we just add the attribute value as-is in the `style` attribute, but now we
have a special exception for color so we add a `#` before the value.
We take the value from a data-* attribute and then add this to the style attribute.
This will probably be OK in most cases, but just to be sure, we check for "weird" characters first.
For now we only allow letters, numbers, dot, hash, and plus and minus sign, because those are the ones I currently know of who are used in MFM.
The data-* attribute remains because it was already considered proper HTML as-is.
When typing MFM, a sugestor drop-down appears so you can see and/or choose what MFM function to use
The new MFM functions we support have now also been added
The `span`'s needed an inline-block for the transform to wrok
I also added an `overflow: hidden;` because these functions can make the text go beyond the borders of the StatusBody
With `overflow: hidden;`, it won't show outside of the borders
These now work for the new, FEP-c16b compliant, representation
Nesting also works
It already worked for text and "normal" emoji, but now it also works for custom emoji
Things like `speed=0.1s` now work
I also noticed a class was set on StatusBody, but we don't use it, we use StatusContent.
Therefor I removed it now.
We do still pass the setting through StatusBody to RichContent bc it's used there to decide to not show greentext for arrows when MFM was used.
Note that while this setting still works
* You have to refresh the page to see it working (was already like this, so I didn't touch it here)
* It explicitly checks for content type. If womeone provides MFM-like HTML, then it will still show as greentext if that option is enabled
I think it's a bit inconsistent, but otoh, the inconsistency to me seems more that we ignore the greentext option for one input type specifically
I do still notice generall bugs with MFM.
* Position doesn't seem to work, neither does scale.
* There also seems to be a regression where custom emojis don't become larger any more with e.g. `$[x2 :hehe: ]`
I don't assume the regression is made in this commit, so I add this already. The rest needs to be fixed before merging.
The SCSS that we took from Foundkey in a previous commit, is now working
The settings for disabling MFM or only show animation on hover are working
The previous representation also works and it's clearly marked in the code what is legacy
All the MFM SCSS is now located in one file specifically for MFM, ./src/components/status_content/mfm.scss
This is only SCSS:
* The variables who are provided as data-attributes are not working yet
* `sparkle` also doesn't work
This is part of a bigger work to fix MFM in Akkoma
See <AkkomaGang/akkoma#381>
Here we add the MFM stylesheet as it is used by Foundkey
See <b22e627089>
Foundkey uses MFM and both the Founkey and Akkoma projects and communities, have historically been closely related
As such it makes sense to start with feature-parity with Foundkey
This commit only adds the stylesheet so that correct attribution is given
Properly integrating and making it work will happen in later commits
MFM was defined in three places.
There was ./src/components/status_body/status_body.scss => I moved this to ./src/components/status_content/mfm.scss
There was ./src/components/status_content/status_content.vue => I moved this to ./src/components/status_content/mfm.scss
There's ./static/mfm.css => I kept this as-is
./src/components/status_content/mfm.scss is now being loaded in ./src/components/status_content/status_content.vue
I added a comment in both ./src/components/status_content/mfm.scss and ./static/mfm.css referencing each other
Note that this is just a first step in an overhoal of how MFM is handled. It seemed easier to do this as a first step and then build further on that.
For someone who isn't used to building fe things like this, it's
not always clear to install Node.js or what version.
A line has been added to the installation instructions pointing to
resources where to get it and what version to use. For version I
point to the woodpecker config because that is what the CI uses and
therefor always "tested".
There was a file .node-version who contained a node version, but
this was seriously outdated and removing it didn't seem to break
anything. Assuming it indeed doesn't do anything any more, it seems
better to remove to avoid confusion.
Previously restoring from file would also restore the old version value
breaking upload of the new settings to the server.
Additionallly it didn’t even attempt to sync settings after restore and
was insufferably slow due to individually updating every single setting
with a dispatch. Instead only update changed settings like on server
syncs which usually speeds the process up considerably.
Fixes: AkkomaGang/akkoma-fe#405
If someone repeating a post had a long username, their username would
overflow beyond the bounds of the post.
This fixes this isse by turning the bar displaying the username and
repeat icon into a flexbox.
The backend returns them order by when the post was favourited;
reordering them by post date jumbles everything up each addition
and serves no purpose.
Fixes: AkkomaGang/akkoma-fe#391
Currently translated at 91.9% (964 of 1048 strings)
Translated using Weblate (Vietnamese)
Currently translated at 92.2% (965 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 92.2% (965 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 84.3% (882 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 84.3% (882 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 79.8% (835 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 79.8% (835 of 1046 strings)
Co-authored-by: Nguyễn Gia Phong <cnx@loang.net>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: xarvos <huyngo@disroot.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/vi/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1048 of 1048 strings)
Merge branch 'origin/develop' into Weblate.
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (1046 of 1046 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 99.7% (1045 of 1048 strings)
Translated using Weblate (Polish)
Currently translated at 99.7% (1045 of 1048 strings)
Translated using Weblate (Polish)
Currently translated at 100.0% (1046 of 1046 strings)
Translated using Weblate (Polish)
Currently translated at 100.0% (1046 of 1046 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: subtype <subtype@hollow.capital>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/pl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 80.4% (841 of 1045 strings)
Translated using Weblate (Italian)
Currently translated at 65.3% (683 of 1045 strings)
Co-authored-by: Cuche <cuche@mailbox.org>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/it/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1048 of 1048 strings)
Translated using Weblate (Chinese (Traditional))
Currently translated at 99.2% (1040 of 1048 strings)
Co-authored-by: Toot <toothpicker@users.noreply.translate.akkoma.dev>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hant/
Translation: Pleroma fe/pleroma-fe
Currently translated at 93.7% (983 of 1048 strings)
Translated using Weblate (Spanish)
Currently translated at 93.9% (983 of 1046 strings)
Translated using Weblate (Spanish)
Currently translated at 92.5% (967 of 1045 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: taretka <info@tarteka.net>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/es/
Translation: Pleroma fe/pleroma-fe
This pulls in 267 new emoji:
- all 258 non-deprecated country or macro region
flags (composed by two regional indicators)
- all 3 regional flags currently recommended for general use
(Wales, Scotland, England)
- a few random ones i picked out
- goose
- heart on fire
- heart mending
- transgender flag
- rainbow flag
- pirate flag
The new names are derived from official Unicode names
with minor modifications to fit into the usual shortcode scheme
and dropping the flag_ prefix from country indicators.
Due to a naming conflict the old "japan" emoji
U+1F5FE SILHOUETTE OF JAPAN was renamed to "japan_silhouette".
Easy Japanses (ja_easy) and traditional Chinses (zh_Hant) use
(custom) non-ISO codes in the interface. Because MastoAPI only accepts
ISO 639 codes, the backend will return an error rendering users
unable to do anything unless the post’s language was explicitly set.
It was merged into pleroma-fe on 2022-02-03 in
76547fe66d and imported
into akkoma-fe on 2022-06-08 with the merge commit
f6cf509a04.
However, something went wrong in the merge and while the setting
and its infrastructure exist, it is never used anywhere and @ is
always displayed as text.
Given it existed in this broken state for nearly one and a half years,
never worked on akkoma-fe and no bugs were filed about this, it appears
nobody cares, so let’s just remove it.
Notifications about favourites and follows use .notification-right,
notifications about replies instead use .heading-right.
Previously only the former set a min-width, however the
chosen value of 3em was too small to fit the worst case.
As a consequence, when the timestamp text changes over time,
its element width changes, which may result in neighbouring text
(no longer) needing to wrap to a new line in turn changing the size
of the whole notification box pushing older notification boxes down/up.
These constant movements at the side of the screen can be quite
annoying and confusing when the cause cannot be immediately discerned.
Avoid this, by reserving enough space for any timestamp.
For English, the worst case is the five-character 'XXmin', since the
short identifier for minutes is the longest with three letters.
With two exceptions, all other current localisation also do not exceed
three letters in any short unit identifier up to days.
However, some localisations (e.g. Polish) additionally insert a space
between numerical value and unit. This matches SI recommendations
pushing the worst case to 6 characters.
6 characters will be sufficient for timestamps up to 3 weeks in all
languages (minus prev exceptions), which seems reasonable enough
as beyond this timestamps rarely change anyway.
The aforementioned exceptions being Vietnamese and Occitan,
but in the current localisation all or the relevant short unit
identifiers are identical to the long forms indicating this is
just due to incomplete translation.
Indeed, Vietnamese Wikipedia (read through machine translation) suggests
“ph” is commonly used as unit identifiers for minutes, but the current
localisation fully spells it out as “phút”.
Currently all notifications except follow-related once include
and explicit direction text. (It missing in follow notifs is due to an
omission in 804ba0cdb6b353e0c959c68f44c6a1316c0d6b10 which only added
the newly introduced with-direction to status-related notifs. Before,
presumably all notifs included direction text.)
But in the notification tray horizontal space is scarce
and notifs can already be assumed to only come from the past.
While it might not be too bad for the English localisation’s 4-letter
' ago' suffix, e.g. the Indonesian localisation’s ' yang lalu' needs
10 letters.
Thus instead of fixing the omission for follow-related notifs,
drop direction text from all notification timestamps.
Modern browsers start to tighten down on third-party access to cookies.
E.g. in current Firefox, a warning about the userLanguage cookie was
shown since it did not yet explicitly set the SameSite attribute and the
default is about to change.
The cookie name being referred to as BACKEND_LANGUAGE_COOKIE_NAME
suggests it should be readable by the actual Akkoma backend, which can
live at a different domain than akkoma-fe. Thus explicitly enable
sharing with third-party sites.
No warnings were shown for other cookies, so I assume
this was the only one not yet setting SameSite.
Currently translated at 62.7% (656 of 1046 strings)
Co-authored-by: Jonathan Soares <jontix@murena.io>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/pt/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1046 of 1046 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 9.7% (102 of 1046 strings)
Co-authored-by: Hasan Yıldız <hasanyildiz0@yaani.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/tr/
Translation: Pleroma fe/pleroma-fe
This patch makes StillImage's animation detection return early in cases
where we can't detect the mimetype of the image. It also sets the image
as animated in those cases if the user agent wants reduced motion.
As reduced motion is an accessibility setting, I think it's best to use
a "better safe than sorry" approach, it's better to accidentally mark
something as animated that isn't than to have unblocked animations.
Currently translated at 100.0% (1042 of 1042 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 4.0% (42 of 1042 strings)
Added translation using Weblate (Turkish)
Co-authored-by: Hasan Yıldız <hasanyildiz0@yaani.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/tr/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1041 of 1041 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 99.9% (1040 of 1041 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 99.9% (1040 of 1041 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 99.9% (1039 of 1040 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: SevicheCC <sevicheee@outlook.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 98.5% (1027 of 1042 strings)
Translated using Weblate (French)
Currently translated at 98.3% (1024 of 1041 strings)
Translated using Weblate (French)
Currently translated at 96.9% (1002 of 1033 strings)
Co-authored-by: Thomate <thomas@burdick.fr>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/fr/
Translation: Pleroma fe/pleroma-fe
Currently translated at 71.6% (747 of 1042 strings)
Translated using Weblate (Japanese (ja_EASY))
Currently translated at 71.6% (747 of 1042 strings)
Translated using Weblate (Japanese (ja_EASY))
Currently translated at 54.1% (564 of 1042 strings)
Co-authored-by: Hikaru Shinagawa <hikali.47041@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: kazari <6c577a54-aac9-482a-955e-745c858445e3@simplelogin.com>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ja_EASY/
Translation: Pleroma fe/pleroma-fe
Currently translated at 65.4% (676 of 1033 strings)
Translated using Weblate (Indonesian)
Currently translated at 65.4% (676 of 1033 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: t1 <taaa@fedora.email>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/id/
Translation: Pleroma fe/pleroma-fe
Currently translated at 99.5% (1036 of 1041 strings)
Co-authored-by: Johann <johann@qwertqwefsday.eu>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/de/
Translation: Pleroma fe/pleroma-fe
Previous code multiply with 0.001 before multiplication which leads to a
floating point error. By changing it to division by 1000 after
multiplication this is avoided.
~~(not intended for merging yet, just submitting this for preliminary review and discussion)~~
this patch adds a tab with recently used emojis to the emoji picker: https://akko.lain.gay/notice/ASoGCtyoiXbYPJjqpk
there's a couple of things i'm ~~still trying to work out~~ not totally happy with and i'd appreciate any feedback on them:
* the recentEmojis getter is called very frequently and has to do a possibly somewhat expensive lookup of emoji objects by their `displayName` each time, which i'm not sure is ideal
* ~~emoji reactions on posts added through the picker are picked up by the recentEmojis module, but clicks on existing emoji reactions are not, because `addReaction` in `react_button.js` only currently receives the replacement and not the full emoji object (if there even is one wherever that method is called from)~~ this works now and does the same stupid full search of all emojis by their name which i guess is less bad because this only happens when you hit a reaction emoji button that already existed
Reviewed-on: AkkomaGang/akkoma-fe#283
Co-authored-by: flisk <akkomadev.mvch71fq@flisk.xyz>
Co-committed-by: flisk <akkomadev.mvch71fq@flisk.xyz>
i'm not sure how this code was supposed to work, but the way it was
written would only add statuses to the timeline if they were in reply to
someone the user is following and erroneously filter out posts that
aren't replies.
A simple virtual scroller is now used for the emoji grid. This avoids loading all emoji images at once, saving network bandwidth and reducing load on the server, while also putting less work on the browser's DOM and layout engine.
Co-authored-by: yan <yan@omg.lol>
Reviewed-on: AkkomaGang/akkoma-fe#275
Co-authored-by: yanchan09 <yan@omg.lol>
Co-committed-by: yanchan09 <yan@omg.lol>
Currently, if a user has their follower/follow counts hidden, they cannot access their own list of followers/follows. This makes no real sense and means that they cannot modify those lists without disabling their privacy options.
This fix simply allows those tabs to be accessed no matter if the counts are hidden or not.
Reviewed-on: AkkomaGang/akkoma-fe#246
Co-authored-by: Beefox <bee@beefox.xyz>
Co-committed-by: Beefox <bee@beefox.xyz>
1280px is a pretty common screen width for several resolutions
(1280x720, 1280x800, 1280x1024, etc.). Since it is only 20px less than
the current 1300px minimum, this shouldn't be a big issue to lower the
minimum screen width for the 3-column layout to 1280px.
Closes: AkkomaGang/pleroma-fe#255
Co-authored-by: Francis Dinh <normandy@biribiri.dev>
Reviewed-on: AkkomaGang/akkoma-fe#256
Co-authored-by: Norm <normandy@biribiri.dev>
Co-committed-by: Norm <normandy@biribiri.dev>
The Unicode sequence for the Keycap Number Sign
emoji starts with an ASCII "#" character, which
the browser's URL parser will interpret as a URI
fragment and truncate it before sending the
request to the backend.
Currently translated at 59.4% (614 of 1033 strings)
Translated using Weblate (Indonesian)
Currently translated at 53.0% (548 of 1033 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: t1 <taaa@fedora.email>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/id/
Translation: Pleroma fe/pleroma-fe
Currently translated at 93.9% (967 of 1029 strings)
Co-authored-by: Johann <johann@qwertqwefsday.eu>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/de/
Translation: Pleroma fe/pleroma-fe
when i originally wrote this, for reasons unclear to the present me, i used literal whitespaces to space out the icons on the scope selector
this causes strange inconsistencies in spacing depending on the font being used
akkoma also did not include the whitespace when adding the local-only scope, resulting in even weirder spacing
this corrects all of that by removing the whitespaces and using css instead
Today I learned that akkoma and mastodon (and potentially other activitypub services) offer RSS/Atom feeds for user profiles at `[user profile url].rss`. This PR adds a direct link to the feed because I haven’t seen anything link to the feed on either mastodon-fe or pleroma-fe
Co-authored-by: Charlotte 🦝 Delenk <lotte@chir.rs>
Reviewed-on: AkkomaGang/pleroma-fe#234
Co-authored-by: darkkirb <lotte@chir.rs>
Co-committed-by: darkkirb <lotte@chir.rs>
Ref #81 - this implements a "your request has been sent" message
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/pleroma-fe#231
Allows the handle of users to drop down onto the next line if there isn't enough room in order to improve useability on mobile
Reviewed-on: AkkomaGang/pleroma-fe#226
Co-authored-by: Beefox <bee@beefox.xyz>
Co-committed-by: Beefox <bee@beefox.xyz>
Currently translated at 85.7% (874 of 1019 strings)
Translated using Weblate (Spanish)
Currently translated at 85.7% (874 of 1019 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: mint <they@mint.lgbt>
Co-authored-by: taretka <info@tarteka.net>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/es/
Translation: Pleroma fe/pleroma-fe
implements part of #178, other parts will come later
Co-authored-by: Sol Fisher Romanoff <sol@solfisher.com>
Reviewed-on: AkkomaGang/pleroma-fe#186
Co-authored-by: sfr <sol@solfisher.com>
Co-committed-by: sfr <sol@solfisher.com>
Currently translated at 100.0% (997 of 997 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: sola <spla@mastodont.cat>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ca/
Translation: Pleroma fe/pleroma-fe
I thought it could be neat to have an autocomplete like Misskey has for MFM.
A condition was removed that prevented autocomplete to actually autocomplete stuff when only the first character was entered. It doesn't affect the other autocompletes since none of them display their elements if nothing was actually searched. (in that case MFM returns the full list of elements)
Co-authored-by: solidsanek <solidsanek@outerheaven.club>
Reviewed-on: AkkomaGang/pleroma-fe#183
Reviewed-by: floatingghost <hannah@coffee-and-dreams.uk>
Co-authored-by: solidsanek <solidsanek@noreply.akkoma>
Co-committed-by: solidsanek <solidsanek@noreply.akkoma>
Currently translated at 100.0% (996 of 996 strings)
Translated using Weblate (Japanese (ja_PEDANTIC))
Currently translated at 100.0% (974 of 974 strings)
Translated using Weblate (Japanese (ja_PEDANTIC))
Currently translated at 100.0% (974 of 974 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: Weblate Admin <hannah.ward9001@gmail.com>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ja_PEDANTIC/
Translation: Pleroma fe/pleroma-fe
Currently translated at 97.8% (953 of 974 strings)
Translated using Weblate (French)
Currently translated at 97.7% (952 of 974 strings)
Translated using Weblate (French)
Currently translated at 96.9% (882 of 910 strings)
Co-authored-by: Thomate <thomas@burdick.fr>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/fr/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (974 of 974 strings)
Translated using Weblate (Dutch)
Currently translated at 98.6% (961 of 974 strings)
Translated using Weblate (Dutch)
Currently translated at 95.3% (868 of 910 strings)
Co-authored-by: Fristi <fristi@subcon.town>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/nl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 98.1% (956 of 974 strings)
Co-authored-by: Johann <johann@qwertqwefsday.eu>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/de/
Translation: Pleroma fe/pleroma-fe
Added in all of the major changes that were mentioned in the various release notes that weren't added to the changelog file.
Fixes#91
Reviewed-on: AkkomaGang/pleroma-fe#169
Co-authored-by: Norm <normandy@biribiri.dev>
Co-committed-by: Norm <normandy@biribiri.dev>
Currently translated at 92.6% (843 of 910 strings)
Translated using Weblate (French)
Currently translated at 92.6% (843 of 910 strings)
Co-authored-by: Thomate <thomas@burdick.fr>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/fr/
Translation: Pleroma fe/pleroma-fe
Currently translated at 99.5% (900 of 904 strings)
Translated using Weblate (English)
Currently translated at 99.5% (900 of 904 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: Weblate Admin <hannah.ward9001@gmail.com>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/en/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (860 of 860 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: sola <spla@mastodont.cat>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ca/
Translation: Pleroma fe/pleroma-fe
Currently translated at 86.1% (773 of 897 strings)
Translated using Weblate (Japanese (ja_PEDANTIC))
Currently translated at 86.0% (740 of 860 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: Weblate Admin <hannah.ward9001@gmail.com>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ja_PEDANTIC/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (860 of 860 strings)
Translated using Weblate (Dutch)
Currently translated at 100.0% (859 of 859 strings)
Co-authored-by: Fristi <fristi@subcon.town>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/nl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 84.1% (724 of 860 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: mint <they@mint.lgbt>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/es/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (855 of 855 strings)
Translated using Weblate (Dutch)
Currently translated at 100.0% (853 of 853 strings)
Translated using Weblate (Dutch)
Currently translated at 100.0% (852 of 852 strings)
Translated using Weblate (Dutch)
Currently translated at 100.0% (852 of 852 strings)
Co-authored-by: Fristi <fristi@subcon.town>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/nl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (855 of 855 strings)
Translated using Weblate (Catalan)
Currently translated at 100.0% (855 of 855 strings)
Translated using Weblate (Catalan)
Currently translated at 96.9% (827 of 853 strings)
Translated using Weblate (Catalan)
Currently translated at 97.0% (827 of 852 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: sola <spla@mastodont.cat>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ca/
Translation: Pleroma fe/pleroma-fe
Currently translated at 98.2% (837 of 852 strings)
Translated using Weblate (Dutch)
Currently translated at 98.1% (836 of 852 strings)
Translated using Weblate (English)
Currently translated at 99.6% (849 of 852 strings)
Co-authored-by: Fristi <fristi@subcon.town>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: Weblate Admin <hannah.ward9001@gmail.com>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/en/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/nl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 98.0% (835 of 852 strings)
Translated using Weblate (Dutch)
Currently translated at 98.0% (835 of 852 strings)
Translated using Weblate (Spanish)
Currently translated at 84.3% (719 of 852 strings)
Translated using Weblate (Dutch)
Currently translated at 97.7% (833 of 852 strings)
Translated using Weblate (Spanish)
Currently translated at 83.8% (714 of 852 strings)
Translated using Weblate (English)
Currently translated at 99.6% (849 of 852 strings)
Translated using Weblate (English)
Currently translated at 99.6% (849 of 852 strings)
Translated using Weblate (English)
Currently translated at 99.6% (849 of 852 strings)
Co-authored-by: Fristi <fristi@subcon.town>
Co-authored-by: Hannah Winter <konhat@hotmail.es>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: Weblate Admin <hannah.ward9001@gmail.com>
Co-authored-by: aetios <dijkvanrichard+akkomatranslate@gmail.com>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/en/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/es/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/nl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 97.7% (833 of 852 strings)
Translated using Weblate (Spanish)
Currently translated at 83.8% (714 of 852 strings)
Translated using Weblate (English)
Currently translated at 99.6% (849 of 852 strings)
Translated using Weblate (English)
Currently translated at 99.6% (849 of 852 strings)
Translated using Weblate (English)
Currently translated at 99.6% (849 of 852 strings)
Co-authored-by: Fristi <fristi@subcon.town>
Co-authored-by: Hannah Winter <konhat@hotmail.es>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: Weblate Admin <hannah.ward9001@gmail.com>
Co-authored-by: aetios <dijkvanrichard+akkomatranslate@gmail.com>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/en/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/es/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/nl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 88.6% (754 of 851 strings)
Translated using Weblate (French)
Currently translated at 97.1% (827 of 851 strings)
Translated using Weblate (Dutch)
Currently translated at 86.8% (739 of 851 strings)
Translated using Weblate (French)
Currently translated at 95.6% (814 of 851 strings)
Translated using Weblate (Dutch)
Currently translated at 86.1% (732 of 850 strings)
Translated using Weblate (French)
Currently translated at 94.8% (806 of 850 strings)
Translated using Weblate (Catalan)
Currently translated at 100.0% (850 of 850 strings)
Translated using Weblate (English)
Currently translated at 100.0% (850 of 850 strings)
Co-authored-by: Fristi <fristi@subcon.town>
Co-authored-by: Thomate <thomas@burdick.fr>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: eris <femmediscord@gmail.com>
Co-authored-by: sola <spla@mastodont.cat>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ca/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/en/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/fr/
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/nl/
Translation: Pleroma fe/pleroma-fe
value:"Thanks for taking the time to file this bug report! Please try to be as specific and detailed as you can, so we can track down the issue and fix it as soon as possible."
- type:input
id:version
attributes:
label:"Version"
description:"Which version of pleroma-fe are you running? If running develop, specify the commit hash."
placeholder:"e.g. 2022.11, 40e86998e6"
- type:textarea
id:attempt
attributes:
label:"What were you trying to do?"
validations:
required:true
- type:textarea
id:expectation
attributes:
label:"What did you expect to happen?"
validations:
required:true
- type:textarea
id:reality
attributes:
label:"What actually happened?"
validations:
required:true
- type:dropdown
id:severity
attributes:
label:"Severity"
description:"Does this issue prevent you from using the software as normal?"
options:
- "I cannot use the software"
- "I cannot use it as easily as I'd like"
- "I can manage"
validations:
required:true
- type:checkboxes
id:searched
attributes:
label:"Have you searched for this issue?"
description:"Please double-check that your issue is not already being tracked on [the forums](https://meta.akkoma.dev) or [the issue tracker](https://akkoma.dev/AkkomaGang/pleroma-fe/issues)."
options:
- label:"I have double-checked and have not found this issue mentioned anywhere."
about:"I'd like something to be added to pleroma-fe"
title:"[feat] "
body:
- type:markdown
attributes:
value:"Thanks for taking the time to request a new feature! Please be as concise and clear as you can in your proposal, so we could understand what you're going for."
- type:textarea
id:idea
attributes:
label:"The idea"
description:"What do you think you should be able to do in pleroma-fe?"
validations:
required:true
- type:textarea
id:reason
attributes:
label:"The reasoning"
description:"Why would this be a worthwhile feature? Does it solve any problems? Have people talked about wanting it?"
validations:
required:true
- type:checkboxes
id:searched
attributes:
label:"Have you searched for this feature request?"
description:"Please double-check that your issue is not already being tracked on [the forums](https://meta.akkoma.dev), [the issue tracker](https://akkoma.dev/AkkomaGang/pleroma-fe/issues), or the one for [the backend](https://akkoma.dev/AkkomaGang/akkoma/issues)."
options:
- label:"I have double-checked and have not found this feature request mentioned anywhere."
- label:"This feature is related to the pleroma-fe Akkoma frontend specifically, and not the backend."
The Akkoma project aims to be **enjoyable** for anyone to participate in, regardless of their identity or level of expertise. To achieve this, the community must create an environment which is **safe** and **equitable**; the following guidelines have been created with these goals in mind.
1. **Treat individuals with respect.** Differing experiences and viewpoints deserve to be respected, and bigotry and harassment are not tolerated under any circumstances.
- Individuals should at all times be treated as equals, regardless of their age, gender, sexuality, race, ethnicity, _or any other characteristic_, intrinsic or otherwise.
- Behaviour that is harmful in nature should be addressed and corrected *regardless of intent*.
- Respect personal boundaries and ask for clarification whenever they are unclear.
- (Obviously, hate does not count as merely a "differing viewpoint", because it is harmful in nature.)
2. **Be understanding of differences in communication.** Not everyone is aware of unspoken social cues, and speech that is not intended to be offensive should not be treated as such simply due to an atypical manner of communication.
- Somebody who speaks bluntly is not necessarily rude, and somebody who swears a lot is not necessarily volatile.
- Try to confirm your interpretation of their intent rather than assuming bad faith.
- Someone may not communicate as, or come across as a picture of "professionalism", but this should not be seen as a reason to dismiss them. This is a **casual** space, and communication styles can reflect that.
3. **"Uncomfortable" does not mean "unsafe".** In an ideal world, the community would be safe, equitable, enjoyable, *and* comfortable for all members at all times. Unfortunately, this is not always possible in reality.
- Safety and equity will be prioritized over comfort whenever it is necessary to do so.
- Weaponizing one's own discomfort to deflect accountability or censor an individual (e.g. "white fragility") is a form of discriminatory conduct.
4. **Let people grow from their mistakes.** Nobody is perfect; even the most well-meaning individual can do something hurtful. Everyone should be given a fair opportunity to explain themselves and correct their behaviour. Portraying someone as inherently malicious prevents improvement and shifts focus away from the *action* that was problematic.
- Avoid bringing up past events that do not accurately reflect an individual's current actions or beliefs. (This is, of course, different from providing evidence of a recurring pattern of behaviour.)
---
This document was adapted from one created by ~keith as part of punks default repository template, and is licensed under CC-BY-SA 4.0. The original template is here: <https://bytes.keithhacks.cyou/keith/default-template>
This is a fork of Akkoma-FE from the Pleroma project, with support for new Akkoma features such as:
- MFM support via [marked-mfm](https://akkoma.dev/sfr/marked-mfm)
- Custom emoji reactions
# For Translators
To translate Pleroma-FE, add your language to [src/i18n/messages.js](https://git.pleroma.social/pleroma/pleroma-fe/blob/develop/src/i18n/messages.js). Pleroma-FE will set your language by your browser locale, but you can temporarily force it in the code by changing the locale in main.js.
The [Weblate UI](https://translate.akkoma.dev/projects/akkoma/pleroma-fe/) is recommended for adding or modifying translations for Akkoma-FE.
Alternatively, edit/create `src/i18n/$LANGUAGE_CODE.json` (where `$LANGUAGE_CODE` is the [ISO 639-1 code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) for your language), then add your language to [src/i18n/messages.js](https://akkoma.dev/AkkomaGang/pleroma-fe/src/branch/develop/src/i18n/messages.js) if it doesn't already exist there.
Akkoma-FE will set your language by your browser locale, but you can temporarily force it in the code by changing the locale in main.js.
# FOR ADMINS
You don't need to build Pleroma-FE yourself. Those using the Pleroma backend will be able to use it out of the box.
To use Akkoma-FE in Akkoma, use the [frontend](https://docs.akkoma.dev/stable/administration/CLI_tasks/frontend/) CLI task to install Akkoma-FE, then modify your configuration as described in the [Frontend Management](https://docs.akkoma.dev/stable/configuration/frontend_management/) doc.
## Build Setup
Make sure you have [Node.js](https://nodejs.org/) installed. You can check `/.woodpecker.yml` for which node version the Akkoma CI currently uses.
``` bash
# install dependencies
npm install -g yarn
npm install -g corepack
yarn
# serve with hot reload at localhost:8080
@ -31,7 +39,7 @@ npm run unit
# For Contributors:
You can create file `/config/local.json` (see [example](https://git.pleroma.social/pleroma/pleroma-fe/blob/develop/config/local.example.json)) to enable some convenience dev options:
You can create file `/config/local.json` (see [example](https://akkoma.dev/AkkomaGang/akkoma-fe/src/branch/develop/config/local.example.json)) to enable some convenience dev options:
* `target`: makes local dev server redirect to some existing instance's BE instead of local BE, useful for testing things in near-production environment and searching for real-life use-cases.
* `staticConfigPreference`: makes FE's `/static/config.json` take preference of BE-served `/api/statusnet/config.json`. Only works in dev mode.
@ -47,3 +55,4 @@ Edit config.json for configuration.
### Login methods
```loginMethod``` can be set to either ```password``` (the default) or ```token```, which will use the full oauth redirection flow, which is useful for SSO situations.
# Pleroma-FE configuration and customization for instance administrators
# Akkoma-FE configuration and customization for instance administrators
* *For user configuration, see [Pleroma-FE user guide](../user_guide)*
* *For user configuration, see [Akkoma-FE user guide](../user_guide)*
* *For local development server configuration, see [Hacking, tweaking, contributing](HACKING.md)*
## Where configuration is stored
PleromaFE gets its configuration from several sources, in order of preference (the one above overrides ones below it)
Akkoma-FE gets its configuration from several sources, in order of preference (the one above overrides ones below it)
1. `/api/statusnet/config.json` - this is generated on Backend and contains multiple things including instance name, char limit etc. It also contains FE/Client-specific data, PleromaFE uses `pleromafe` field of it. For more info on changing config on BE, look [here](../backend/configuration/cheatsheet.md#frontend_configurations)
2. `/static/config.json` - this is a static FE-provided file, containing only FE specific configuration. This file is completely optional and could be removed but is useful as a fallback if some configuration JSON property isn't present in BE-provided config. It's also a reference point to check what default configuration are and what JSON properties even exist. In local dev mode it could be used to override BE configuration, more about that in HACKING.md. File is located [here](https://git.pleroma.social/pleroma/pleroma-fe/blob/develop/static/config.json).
3. Built-in defaults. Those are hard-coded defaults that are used when `/static/config.json` is not available and BE-provided configuration JSON is missing some JSON properties. ( [Code](https://git.pleroma.social/pleroma/pleroma-fe/blob/develop/src/modules/instance.js) )
1. `/api/statusnet/config.json` - this is generated on Backend and contains multiple things including instance name, char limit etc. It also contains FE/Client-specific data, Akkoma-FE uses `pleromafe` field of it. For more info on changing config on BE, look [here](https://docs.akkoma.dev/stable/configuration/cheatsheet.md#frontend_configurations)
2. `/static/config.json` - this is a static FE-provided file, containing only FE specific configuration. This file is completely optional and could be removed but is useful as a fallback if some configuration JSON property isn't present in BE-provided config. It's also a reference point to check what default configuration are and what JSON properties even exist. In local dev mode it could be used to override BE configuration, more about that in HACKING.md. File is located [here](https://akkoma.dev/AkkomaGang/akkoma-fe/src/branch/develop/static/config.json).
3. Built-in defaults. Those are hard-coded defaults that are used when `/static/config.json` is not available and BE-provided configuration JSON is missing some JSON properties. ( [Code](https://akkoma.dev/AkkomaGang/akkoma-fe/src/branch/develop/src/modules/instance.js) )
## Instance-defaults
@ -59,7 +59,7 @@ Instance `logo`, could be any image, including svg. By default it assumes logo u
`logoMargin` allows you to adjust vertical margins between logo boundary and navbar borders. The idea is that to have logo's image without any extra margins and instead adjust them to your need in layout.
### `minimalScopesMode`
Limit scope selection to *Direct*, *User default* and *Scope of post replying to*. This also makes it impossible to reply to a DM with a non-DM post from PleromaFE.
Limit scope selection to *Direct*, *User default* and *Scope of post replying to*. This also makes it impossible to reply to a DM with a non-DM post from Akkoma-FE.
### `nsfwCensorImage`
Use custom image for NSFW'd images
@ -70,9 +70,6 @@ Default post formatting option (markdown/bbcode/plaintext/etc...)
### `redirectRootNoLogin`, `redirectRootLogin`
These two settings should point to where FE should redirect visitor when they login/open up website root
### `scopeCopy`
Copy post scope (visibility) when replying to a post. Instance-default.
### `sidebarRight`
Change alignment of sidebar and panels to the right. Defaults to `false`.
@ -80,7 +77,7 @@ Change alignment of sidebar and panels to the right. Defaults to `false`.
Show panel showcasing instance features/settings to logged-out visitors
### `showInstanceSpecificPanel`
This allows you to include arbitrary HTML content in a panel below navigation menu. PleromaFE looks for an html page `instance/panel.html`, by default it's not provided in FE, but BE bundles some [default one](https://git.pleroma.social/pleroma/pleroma/blob/develop/priv/static/instance/panel.html). De-facto instance-defaults, since user can hide instance-specific panel.
This allows you to include arbitrary HTML content in a panel below navigation menu. Akkoma-FE looks for an html page `instance/panel.html`, by default it's not provided in FE, but BE bundles some [default one](https://git.pleroma.social/pleroma/pleroma/blob/develop/priv/static/instance/panel.html). De-facto instance-defaults, since user can hide instance-specific panel.
### `subjectLineBehavior`
How to handle subject line (CW) when replying to a post.
PleromaFE is an SPA (Single-Page Application) backed by [Vue](https://vuejs.org/) framework. It means that it's just a nearly-empty HTML page with bunch of JavaScript that actually generates and controls DOM (i.e. html elements) in Runtime. Currently, there's no way around it - you have to have Javascript enabled in the browser to make it work, there is a theoretical possibility to generate some HTML server-side but it's not implemented yet.
Akkoma-FE is an SPA (Single-Page Application) backed by [Vue](https://vuejs.org/) framework. It means that it's just a nearly-empty HTML page with bunch of JavaScript that actually generates and controls DOM (i.e. html elements) in Runtime. Currently, there's no way around it - you have to have Javascript enabled in the browser to make it work, there is a theoretical possibility to generate some HTML server-side but it's not implemented yet.
You can serve static html page and everything from any HTTP(S) server but currently it will try to access /api/ path at same domain it's running on, meaning that as of right now you cannot put it on one domain and access the other without proxying requests.
@ -25,7 +25,7 @@ This could be a bit trickier, you basically need steps 1-4 from *develop build*
### Replacing your instance's frontend with custom FE build
This is the most easiest way to use and test FE build: you just need to copy or symlink contents of `dist` folder into backend's [static directory](../backend/configuration/static_dir.md), by default it is located in `instance/static`, or in `/var/lib/pleroma/static` for OTP release installations, create it if it doesn't exist already. Be aware that running `yarn build` wipes the contents of `dist` folder.
This is the most easiest way to use and test FE build: you just need to copy or symlink contents of `dist` folder into backend's [static directory](https://docs.akkoma.dev/stable/configuration/static_dir/), by default it is located in `instance/static`, or in `/var/lib/pleroma/static` for OTP release installations, create it if it doesn't exist already. Be aware that running `yarn build` wipes the contents of `dist` folder.
### Running production build locally or on a separate server
@ -67,19 +67,19 @@ server {
### API, Data, Operations
In 99% cases PleromaFE uses [MastoAPI](https://docs.joinmastodon.org/api/) with [Pleroma Extensions](../backend/API/differences_in_mastoapi_responses.md) to fetch the data. The rest is either QvitterAPI leftovers or pleroma-exclusive APIs. QvitterAPI doesn't exactly have documentation and uses different JSON structure and sometimes different parameters and workflows, [this](https://twitter-api.readthedocs.io/en/latest/index.html) could be a good reference though. Some pleroma-exclusive API may still be using QvitterAPI JSON structure.
In 99% cases Akkoma-FE uses [MastoAPI](https://docs.joinmastodon.org/api/) with [Pleroma Extensions](https://docs.akkoma.dev/stable/differences_in_mastoapi_responses.md) to fetch the data. The rest is either QvitterAPI leftovers or pleroma-exclusive APIs. QvitterAPI doesn't exactly have documentation and uses different JSON structure and sometimes different parameters and workflows, [this](https://twitter-api.readthedocs.io/en/latest/index.html) could be a good reference though. Some pleroma-exclusive API may still be using QvitterAPI JSON structure.
PleromaFE supports both formats by transforming them into internal format which is basically QvitterAPI one with some additions and renaming. All data is passed trough [Entity Normalizer](https://git.pleroma.social/pleroma/pleroma-fe/-/blob/develop/src/services/entity_normalizer/entity_normalizer.service.js) which can serve as a reference of API and what's actually used, it's also a host for all the hacks and data transformation.
Akkoma-FE supports both formats by transforming them into internal format which is basically QvitterAPI one with some additions and renaming. All data is passed trough [Entity Normalizer](https://akkoma.dev/AkkomaGang/akkoma-fe/src/branch/develop/src/services/entity_normalizer/entity_normalizer.service.js) which can serve as a reference of API and what's actually used, it's also a host for all the hacks and data transformation.
For most part, PleromaFE tries to store all the info it can get in global vuex store - every user and post are passed trough updating mechanism where data is either added or merged with existing data, reactively updating the information throughout UI, so if in newest request user's post counter increased, it will be instantly updated in open user profile cards. This is also used to find users, posts and sometimes to build timelines and/or request parameters.
For most part, Akkoma-FE tries to store all the info it can get in global vuex store - every user and post are passed trough updating mechanism where data is either added or merged with existing data, reactively updating the information throughout UI, so if in newest request user's post counter increased, it will be instantly updated in open user profile cards. This is also used to find users, posts and sometimes to build timelines and/or request parameters.
PleromaFE also tries to persist this store, however only stable data is stored, such as user authentication and preferences, user highlights. Persistence is performed by saving and loading chunk of vuex store in browser's LocalStorage/IndexedDB.
Akkoma-FE also tries to persist this store, however only stable data is stored, such as user authentication and preferences, user highlights. Persistence is performed by saving and loading chunk of vuex store in browser's LocalStorage/IndexedDB.
TODO: Refactor API code and document it here
### Themes
PleromaFE uses custom theme "framework" which is pretty much just a style tag rendered by vue which only contains CSS3 variables. Every color used in UI should be derived from theme. Theme is stored in a JSON object containing color, opacity, shadow and font information, with most of it being optional.
Akkoma-FE uses custom theme "framework" which is pretty much just a style tag rendered by vue which only contains CSS3 variables. Every color used in UI should be derived from theme. Theme is stored in a JSON object containing color, opacity, shadow and font information, with most of it being optional.
The most basic theme can consist of 4 to 8 "basic colors", which is also what previous version of themes allowed, with all other colors being derived from those basic colors, i.e. "light background" will be "background" color lightened/darkened, "panel header" will be same as "foreground". The idea is that you can specify just basic color palette and everything else will be generated automatically, but if you really need to tweak some specific color - you can.
Akkoma-FE is the default user-facing frontend for Pleroma. It's user interface is modeled after Qvitter which is modeled after an older Twitter design. It provides a simple 2-column interface for microblogging. While being simple by default it also provides many powerful customization options.
## How can I use it?
If your instance uses Akkoma-FE, you can acces it by going to your instance (e.g. <https://pleroma.soykaf.com>). You can read more about it's basic functionality in the [Akkoma-FE User Guide](./user_guide/). We also have [a guide for administrators](./CONFIGURATION.md) and for [hackers/contributors](./HACKING.md).
Pleroma-FE is the default user-facing frontend for Pleroma. If your instance uses Pleroma-FE, you can access it by going to your instance (e.g. <https://pleroma.soykaf.com>). After logging in you will have two columns in front of you. Here we're going to keep it to the default behaviour, but some instances swap the left and right columns. If you're on such an instance what we refer to as the left column will be on your right and vice versa.
Akkoma-FE is the default user-facing frontend for Pleroma. If your instance uses Akkoma-FE, you can access it by going to your instance (e.g. <https://pleroma.soykaf.com>). After logging in you will have two columns in front of you. Here we're going to keep it to the default behaviour, but some instances swap the left and right columns. If you're on such an instance what we refer to as the left column will be on your right and vice versa.
### Left column
- first block: This section is dedicated to [posting](posting_reading_basic_functions.md)
- second block: Here you can switch between the different views for the right column.
- Optional third block: This is the Instance panel that can be activated, but is deactivated by default. It's fully customisable by instance admins and by default has links to the Pleroma-FE and Mastodon-FE.
- Optional third block: This is the Instance panel that can be activated, but is deactivated by default. It's fully customisable by instance admins and by default has links to the Akkoma-FE and Mastodon-FE.
- fourth block: This is the Notifications block, here you will get notified whenever somebody mentions you, follows you, repeats or favorites one of your statuses
@ -15,13 +15,13 @@ Posts will contain the text you are posting, but some content will be modified:
Let's clear up some basic stuff. When you post something it's called a **post** or it could be called a **status** or even a **toot** or a **prööt** depending on whom you ask. Post has body/content but it also has some other stuff in it - from attachments, visibility scope, subject line...
**Emoji** are small images embedded in text, there are two major types of emoji: [unicode emoji](https://en.wikipedia.org/wiki/Emoji) and custom emoji. While unicode emoji are universal and standardized, they can appear differently depending on where you are using them or may not appear at all on older systems. Custom emoji are a more *fun* kind - instance administrator can define many images as *custom emoji* for their users. This works very simple - custom emoji is defined by its *shortcode* and an image, so that any shortcode enclosed in colons get replaced with image if such shortcode exist.
Let's say there's a `:pleroma:` emoji defined on an instance. That means
> First time using :pleroma: pleroma!
Let's say there's a `:akkoma:` emoji defined on an instance. That means
> First time using :akkoma: akkoma!
will become
> First time using  pleroma!
will become
> First time using  akkoma!
Note that you can only use emoji defined on your instance, you cannot "copy" someone else's emoji, and will have to ask your administrator to copy emoji from other instance to yours.
Note that you can only use emoji defined on your instance, you cannot "copy" someone else's emoji, and will have to ask your administrator to copy emoji from other instance to yours.
Lastly, there's two convenience options for emoji: an emoji picker (smiley face to the right of "submit" button) and autocomplete suggestions - when you start typing :shortcode: it will automatically try to suggest you emoji and complete the shortcode for you if you select one. If emoji doesn't show up in suggestions nor in emoji picker it means there's no such emoji on your instance, if shortcode doesn't match any defined emoji it will appear as text.
**Attachments** are fairly simple - you can attach any file to a post as long as the file is within maximum size limits. If you're uploading explicit material you can mark all of your attachments as sensitive (or add the `#nsfw` tag) - it will hide the images and videos behind a warning so that it won't be displayed instantly.
@ -42,7 +42,7 @@ A few things to consider about the security and usage of these scopes:
- Changing scopes during a thread or adding people to a direct message will not retroactively make them see the whole conversation. If you add someone to a direct message conversation, they will not see the post that happened before they were mentioned.
* **Reply-to** if you are replying to someone, your post will also contain a note that your post is referring to the post you're replying to. Person you're replying to will receive a notification *even* if you remove them from mentioned people. You won't receive notifications when replying to your own posts, but it's useful to reply to your own posts to provide people some context if it's a follow-up to a previous post. There's a small "Reply to ..." label under post author's name which you can hover on to see what post it's referring to.
Sometimes you may encounter posts that seem different than what they are supposed to. For example, you might see a direct message without any mentions in the text. This can happen because internally, the Fediverse has a different addressing mechanism similar to email, with `to` and `cc` fields. While these are not directly accessible in PleromaFE, other software in the Fediverse might generate those posts. Do not worry in these cases, these are normal and not a bug.
Sometimes you may encounter posts that seem different than what they are supposed to. For example, you might see a direct message without any mentions in the text. This can happen because internally, the Fediverse has a different addressing mechanism similar to email, with `to` and `cc` fields. While these are not directly accessible in Akkoma-FE, other software in the Fediverse might generate those posts. Do not worry in these cases, these are normal and not a bug.
## Rich text
@ -51,7 +51,7 @@ By default new posts you make are plaintext, meaning you can't make text **bold*
Here is a small example of some text in markdown.
```
This is an example of markdown text using **bold** and *cursive* text.
This is an example of markdown text using **bold** and *cursive* text.
To get a newline we add two spaces at the end of the previous line.
Let's also add a list
@ -65,6 +65,16 @@ If you set the input-method to Markdown, and post this, it will look something l
To render MFM, you will need to turn on "Render Misskey Markdown" in
the settings modal.
## Other actions
In addition to posting you can also *favorite* posts also known as *liking* them and *repeat* posts (also known as *retweeting*, *boosting* and even *reprööting*). Favoriting a post increments a counter on it, notifies the post author of your affection towards that post and also adds that post to your "favorited" posts list (in your own profile, "Favorites" tab). Reprööting a post does all that and also repeats this post to your followers and your profile page with a note "*user* repeated post".
@ -83,7 +83,7 @@ Here you can change your password, revoke access tokens, configure 2-factor auth
## Theme
Here you can change the look and feel of Pleroma-FE. You can choose from several instance-provided presets and you can load one from file and save current theme to file. Before you apply new theme you can see what it will look like approximately in preview section.
Here you can change the look and feel of Akkoma-FE. You can choose from several instance-provided presets and you can load one from file and save current theme to file. Before you apply new theme you can see what it will look like approximately in preview section.
The themes engine was made to be easy to use while giving an option for powerful in-depth customization - you can just tweak colors on "Common" tab and leave everything else as is.
@ -6,6 +6,7 @@ You have several timelines to browse trough
- **Bookmarks** all the posts you've bookmarked. You can bookmark a post by clicking the three dots on the bottom right of the post and choose Bookmark.
- **Direct Messages** all posts with `direct` scope addressed to you or mentioning you.
- **Public Timelines** all public posts made by users on the instance you're on
- **Bubble Timeline** all public posts from instances recommended by your admin(s) in the instance settings. This won't appear if they haven't set anything up for it.
- **The Whole Known Network** also known as **TWKN** or **Federated Timeline** - all public posts known by your instance. Due to nature of the network your instance may not know *all* the posts on the network, so only posts known by your instance are shown there.
Note that by default you will see all posts made by other users on your Home Timeline, this contrast behavior of Twitter and Mastodon, which shows you only non-reply posts and replies to people you follow. You can change said behavior in the [settings](settings.md#filtering).
@ -4,7 +4,7 @@ When you see someone, you can click on their user picture to view their profile,
**Following** is self-explanatory, it adds them to your Home Timeline, lists you as a follower and gives you access to follower-only posts if they have any.
**Muting** collapses posts and notifications made by them, giving you an option to see the post if you're curious. Clients other than PleromaFE may completely remove their posts.
**Muting** collapses posts and notifications made by them, giving you an option to see the post if you're curious. Clients other than Akkoma-FE may completely remove their posts.
**Blocking** a user removes them from your timeline and notifications and prevents them from following you (automatically unfollows them from you).
Pleroma-FE is the default user-facing frontend for Pleroma. It's user interface is modeled after Qvitter which is modeled after an older Twitter design. It provides a simple 2-column interface for microblogging. While being simple by default it also provides many powerful customization options.
## How can I use it?
If your instance uses Pleroma-FE, you can acces it by going to your instance (e.g. <https://pleroma.soykaf.com>). You can read more about it's basic functionality in the [Pleroma-FE User Guide](./user_guide/). We also have [a guide for administrators](./CONFIGURATION.md) and for [hackers/contributors](./HACKING.md).
