WIP: codeberg design & gettext translation #12
No reviewers
Labels
No labels
Kind: Breaking
Kind: Bug
Kind: Documentation
Kind: Enhancement
Kind: Feature
Kind: Maintenance
Kind: Question
Kind: Security
Kind: Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed: Confirmed
Reviewed: Duplicate
Reviewed: Invalid
Reviewed: Wontfix
Status
Blocked
Status
Completed
Status
Help wanted
Status
In progress
Status
Needs feedback
Status
Stale
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Codeberg-e.V./registration-server!12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "codeberg-design"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR solves Codeberg/Design#26 if it's done, and depends on Codeberg/build-deploy-gitea#51.
It basically removes all static resources, uses the ones from design.codeberg.org instead, and adjusts the form for Halfmoon CSS.
Also, it uses the gettext package from Snapcraft (https://github.com/snapcore/go-gettext) for translation, so it will work with any translation tool we might introduce at some point. And, if we're at it, it also uses Go's non-standard package for parsing the
Accept-Languageheader, as it reduces the amount of work required there.go generateto build the translation files. I'd love to make this run in Docker instead though... 🙈)Oh, I would recommend using the split view for this PR due to all the removed static files.
Nice! Do you want to deploy a preliminary PR to https://join.codeberg-test.org?
For this PR I'd like to fix the UI/UX fine-tuning and the actual form functionality first.
I think that making build-deploy-gitea#51 available on production (it's already deployed to test) should be a higher priority, as that's actually done, and would make deploying this one much easier. It still depends on build-deploy-gitea#50, and I think that build-deploy-gitea#52 should actually be rebased onto master after merging build-deploy-gitea#50 (and there's still some open discussion for build-deploy-gitea#52).
24a3607964to56ba6c7629Alright, form functionality is not working again yet, but I have deployed it to join.codeberg-test.org
Please note the following (from the translations which are WIP)
Should we formulate this more carefully, like you "might ..."? Because there's currently no such feature and stuff like CI is still undecided.
Do we really want to advertise for honorary membership that actively? It's kinda designed to be something exlusively for people that are proposed for this. Also, since the general assembly has to vote over this, many requests that are not conidered worth would result in a lot of unnecessary votes.
From the bylaws:
I'd prefer not to allow for an application for honorary members, but for the discount. I think, granting the discount of 12 € per year for students and people with small financial opportunities is a more common thing, and since this has to be applied for it makes perfectly sense to include this in the registration form.
Yes, agree.
While we have to make features that are experimental available to a limited group, we probably should not suggest that this will happen regularly.
@momar
Really nice work. This totally makes sense, also since I am in the process of building better automatic accounting, wire transfers should already be no problem for us to manage.
I propose to rephase this (I can take care of the German version as well) to something like ~
I think this sounds more like "you'll never be behind" by rephrasing it more generally (could also be interpreted as "people that use Codeberg are always at the forefront ...") but isn't suggesting that there are always new features unlocked for members only.
It kind of feels as if such promises might invite unfortunate expectations.
What do you mean exactly? Do you have a change in mind?
As non-profit org we are not selling a members-only subscription service (to keep non-profit status we are allowed to do so only to the extend that this serves the common good and goals defined in the statutes). Any wording that might get misinterpreted as advertising members-only benefits might get considered harmful here.
I like @fnetX's wording as it is advertising mainly influence as a member-only benefit (which it legally is). To me, if I read it, I would assume that I would be invited to a potential closed alpha first as a member, but would not get exclusive features on the platform just because I am a member.
Agree, +1
We might want to look at a rewording of the SEPA text to solve Codeberg/Community#268 (as simple as adding something like 'Creditor ID:' inside the brackets).
Is the text exactly required in it's current form (provided by a bank or something) or are we free to modify it. (I think the latter one, otherwise translations would similarly be an issue)
The wording of these text templates and their translations is mandated by the European Payments Council: https://www.europeanpaymentscouncil.eu/document-library/other/sepa-direct-debit-mandate-template
Hi there and greetings from the 1st Codeberg Hackathon.
We try to resolve this pull request and merged the commits to a branch named hackathon.
We opened #18, #19 and #20 for further work.
We hope to resolve your pullrequest by merging the hackthon branch at the end of the hackathon.
Pull request closed