no ref
Arabic locale done for search, comments, newsletter . once pulled I'll start translating the portal.
This translation is a part of ACLSS efforts to translate more open source projects to Arabic.
no ref
Added most no-brainer Hebrew translations but left the more complicated ones to people better equipped to translate them. Better something than nothing at all.
Also, Hebrew is an RTL language, so exclamation points and dots at the end of a sentence should appear at the leftmost part, but the translation files are LTR, as all JSON files are. Just putting it out there. This should be considered when using an RTL language translation.
---------
Co-authored-by: Steve Larson <9larsons@gmail.com>
no ref
- Changed _"Gói theo dõi"_ to _"Gói thành viên"_ for a better match to
the grammar and correct usage in Vietnamese
- Clarified the definition of **Subscription plan** (_"Gói thành viên"_
instead of _"Gói"_)
- Removed plural **emails** because it is not logical in Vietnamese
- Added _"Sort by"_ in comment.json
- Added _"Sorry, no recommendations are available right now."_ in
portal.json
- Changed placeholder text "and" to "&" for shorter and show full
sentence (mobile) in search.json
no ref
Added Prometheus metrics for the job queue throughput and email analytics throughput. We'll likely keep these around as good metrics to keep an eye on, though for the moment their primary function is to establish a baseline for users w/o the job queue enabled so we can observe the full impact once switching it on.
no ref
- [x] Created a new folder `ne` based on locale code for Nepali locale
inside `ghost/i18n/locales/`
- [x] Cloned 6 new JSON files pertaining to `en` folder from English
locale.
- [x] Added all field translations from English to Nepali for
`ghost.json` file.
- [x] Added all field translations from English to Nepali for
`search.json` file.
- [x] Added all field translations from English to Nepali for
`signup-form.json` file.
- [ ] TODO: Remaining 3 other files viz. `comments`, `newsletter`, and
`portal`.
"Thank you for creating Ghost and making it open source.": "Ghost
सिर्जना गरेर यसलाई ओपन सोर्स बनाउनु भएकोमा धन्यवाद।"
no ref
Suggestion to update the translation for 'A label for the thumbs-up response in member feedback at the bottom of emails' to 'I like it' and 'I don't like it,' as this phrasing sounds better and is more appropriate in Brazilian Portuguese. Thank you.
ref
https://linear.app/ghost/issue/ENG-1769/improve-pool-utilization-metric
- Currently the connection pool metrics are all point in time metrics,
and with a scrape interval of 15s this doesn't tell us a whole lot about
what's happening in the pool.
- This commit adds a Summary metric to track the elapsed time each
transaction has to wait to acquire a connection from the pool, which
should be a good indication of contention in the pool.
- Also moved the call to `prometheusClient.instrumentKnex` to after `initCore` in the boot process, because the metric depends on event listeners on `knex.client.pool`, and the pool gets destroyed and recreated in `initCore`, which removes the listeners
no issue
- Since we decided to use the pushgateway instead of running a metrics
server, this removes the metrics server and its e2e tests
- We may reintroduce it later, but for now this is a simpler setup
no issue
- The `instrumentKnex` method was directly accessing the `promClient`
instance to create custom metrics, and keeping track of them manually in
a `customMetrics` map. This isn't necessary, since the metrics are all
tracked within the `promClient` instance's registry. This method now
uses the `prometheusClient.register...()` methods to create the metrics,
and retrieves them with the `getMetric()` method to reduce duplication
of work and manual bookkeeping
- This also removes the query count metric, as there is a count already
included in the query duration Summary metric
ref https://linear.app/ghost/issue/PLG-230
closes https://linear.app/ghost/issue/PLG-256
Adding an in-reply-to reference link/snippet to reply forms was proving difficult with the previous setup due the amount of data that needed to be passed up and down a deeply nested component tree. This refactor lays the groundwork for making that easier and aims to make form autoclose behaviour more centralised by keeping the open form state in app context and the opening/closing of forms in actions so there's less need for messy local state and to drill functions down the component tree.
- replaces `openFormCount` context state with an `openCommentForms` array
- keeping detailed open form references in the application state means the display of forms is centrally managed rather than managed via local state inside components
- it simplifies some of the problems faced with the `<PublishedComment>` component that previously managed form display. That component is re-used for both the top-level comment as well as replies even though replying on a reply puts the top-level comment into reply mode meaning we had a mess of local state and passed-through functions to work around the component having varying behaviour depending on nesting level
- `openFormCount` is still available on the application state via `useMemo` on the provider meaning the implementation of `openCommentForms` is hidden from app code that just needs to know if forms are open
- removes `<AutocloseForm>` as the autoclose behaviour is now controlled via the `openCommentForm` action
- updated `<Form>` so it manages the "has unsaved changes" properties on `openFormComments` ready for use by `openCommentForm`'s autoclosing behaviour
close
https://linear.app/ghost/issue/AP-528/remove-unnecessary-separator-after-last-list-items
- Previously, in some components, we relied on CSS and all elements in
the list being the same type of an HTML element to show the separator.
Now, we've extracted the separator into its own component and place
after all items during mapping except the last one.
no issues
- with gscan v4.46.0, we introduced a new rule for the custom fonts
feature
- this updates the valid theme zip file to make the theme tests work
with the new rules
no issue
- Currently the prometheus client is only initialized on boot if enabled
via config, but if it's required in other files (i.e. to create a custom
metric) it will be initialized then
- This commit explicitly checks if the prometheus client is enabled via
config before initializing it, thus preventing it from being initialized
when disabled
ref
https://linear.app/ghost/issue/ENG-1771/add-utility-functions-to-easily-create-custom-metrics
- Currently adding custom metrics to our prometheus client requires you
to directly access the `prometheusClient.client` to create the metrics
- This isn't super convenient, as you then have to either keep the
metric in a local variable, or manually get it from the
`prometheusClient.client.register`
- This commit exposes some utility functions for registering metrics on
the `prometheusClient` class, and for retrieving metrics that have
already been registered
no ref
Stripe made changes (again) that causes our donation tests to fail. This
round we use an if statement to try to make it more inclusive of cases,
as I've seen them use an accordion button, card button, and no button
all in the past 12h.
no issue
Stripe recently updated their checkout page to use React with Framer
Motion for animations, causing our Playwright tests to intermittently
fail when attempting to click the “Card” payment button. The standard
Playwright `.click()` method was unable to interact with the button
reliably due to animation-related delays, where the button was present
in the DOM but not fully interactable according to Playwright’s strict
visibility checks.
Switching to `dispatchEvent('click')` directly fires the click event on
the button, bypassing Playwright’s visibility and interactability
checks. This ensures the test can proceed without waiting for animations
to fully complete, resolving the issue with the Stripe checkout flow.
ref https://linear.app/ghost/issue/ENG-1749
Batch sending tests were failing with MySQL fairly regularly. It appears
to be a race condition where the listener for the batch sending job
having completed is returning too early, causing the subsequent
Bookshelf data model refresh to happen too soon.
This is a fundamental flaw in the JobManager awaitCompletion handler
(and how the batch sending system interacts with it) as there's no way
to identify one batch from another - they all use the same name, and we
don't pass along any metadata.
no issue
- running tests locally, especially in UI mode, would often result in an avatar saturation test failing
- the cause was calculating saturation for an element that still had it's opacity animating in
- added a test util function that waits for an element in a frame to reach full opacity
- used function in test to ensure we have a stable element before calculating the color saturation
ref https://linear.app/ghost/issue/AP-585
If preferredUsername is not a string, and we attempt to render it, we
will crash the entire React application!
