Grammar corrections

content/posts/whats-up-arm64/index.de.md

@@ -28,17 +28,17 @@ Diese sind für den Hauptbetrieb prinzipiell nicht wirklich spürbar, stören un
 
 > Worum geht's fragt ihr?
 
-Lieb, dass ihr fragt! Es geht im genauen um die Hyperscan Bibliothek bzw. die Implementation von Hyperscan bzw. Vectorscan (wie es auf ARM64 heißt) für Rspamd. Besagter Hyperscan kompiliert regelmäßig Regex Einträge, welche durch den Betrieb von mailcow dynamisch erzeugt werden und zur Erkennung von Spam benötigt wird. Genauer gesagt dient Hyperscan hier als Performanceboost, da die Kompilierung der Regex Einträge somit nicht immer wieder neu passieren muss, sondern dieser kompiliert bleibt.
+Danke für die Frage! Genauer gesagt geht es um die Hyperscan Bibliothek bzw. die Implementierung von Hyperscan bzw. Vectorscan (wie es auf ARM64 heißt) für Rspamd. Besagter Hyperscan kompiliert regelmäßig Regex-Einträge, die durch den Betrieb von mailcow dynamisch erzeugt werden und zur Erkennung von Spam benötigt werden. Genauer gesagt dient Hyperscan hier als Performance-Booster, da die Kompilierung der Regex-Einträge so nicht immer wieder neu durchgeführt werden muss, sondern kompiliert bleibt.
 
 > Was ist nun das Problem?
 
-Das Problem ist nun, dass besagter Hyperscan (Vectorscan) auf ARM64 zum aktuellen Zeitpunkt nicht richtig funktioniert bzw. die Kompilierung nach einem Neustart hinfällig ist, da er diese nicht mehr laden kann. Man muss aber auch dazu sagen, dass Rspamd erst mit der aktuellen Version 3.5 nativen ARM64 Support erhalten hat und damit noch einige Fehler aufweisen lassen kann.
+Das Problem ist nun, dass der besagte Hyperscan (Vectorscan) auf ARM64 zur Zeit nicht richtig funktioniert bzw. die Kompilierung nach einem Neustart hinfällig ist, da er diese nicht mehr laden kann. Allerdings muss man dazu sagen, dass Rspamd erst mit der aktuellen Version 3.5 nativen ARM64-Support erhalten hat und daher noch einige Fehler aufweisen kann.
 
-Der Hauptgrund, warum wir das ganze zurückhalten (obwohl die eigentliche Funktionalität bereits gegeben ist und von einigen Testern [DANKE] bereits erfolgreich getestet wurde) ist der, dass es zu einigen Warnungen in der Konsole kommt, welche unerfahrenere Nutzer verwirren bzw. beängstigen kann. Ebenfalls kann durch dieses Problem eine gleichwertige Performance nicht garantiert werden.
+Der Hauptgrund, warum wir das Ganze zurückhalten (obwohl die eigentliche Funktionalität bereits vorhanden ist und von einigen Testern [DANKE] bereits erfolgreich getestet wurde) ist, dass es einige Warnungen in der Konsole gibt, die unerfahrene Benutzer verwirren oder verschrecken können. Außerdem kann aufgrund dieses Problems keine gleichwertige Leistung garantiert werden.
 
-Zusätzlich dazu kommt noch der Fakt, dass einige wichtige Kernkomponenten wie bspw. Dovecot (er insbesondere) mit dem Nightly Release von ARM64 von uns selbst kompiliert werden muss, da das Dovecot Team keinen nativen ARM64 Support anbieten wird und wir nun mal im mailcow Stack die Pakete von Ihnen direkt beziehen und nicht über das APT Repo von Debian bspw. an die Versionen gelangen wie bei Postfix bspw.
+Dazu kommt noch die Tatsache, dass einige wichtige Kernkomponenten wie z.B. Dovecot (insbesondere er) mit dem Nightly Release von ARM64 von uns selbst kompiliert werden müssen, da das Dovecot Team keinen nativen ARM64 Support anbieten wird und wir die Pakete im mailcow Stack direkt von Ihnen beziehen und nicht wie z.B. bei Postfix über das APT Repo von Debian an die Versionen kommen.
 
-Dies kann zum aktuellen Zeitpunkt ungeahnte Konsequenzen mit sich ziehen, welche mit einer größeren Testrunde geklärt bzw. beleuchtet werden müssen.
+Dies kann zum jetzigen Zeitpunkt ungeahnte Konsequenzen mit sich bringen, die mit einer größeren Testrunde geklärt bzw. beleuchtet werden müssen.
 
 Wir wollen den ARM64 Support nicht einfach "hinrotzen" nur damit wir sagen können "Hey, mailcow kann jetzt auch ARM64, schaut mal her!!!" sondern ihn in den normalen Releasecycle und die normale mailcow Architektur integrieren, sodass wir nicht zwei Repos, sondern ein einziges Repo mit demselben Inhalt für x86 und ARM64 pflegen können.
 
@@ -61,11 +61,11 @@ Und vermutlich werdet ihr damit auch nicht ganz falsch liegen, aber wir selbst m
 
 ---
 
-Wir planen solche "Ask the Developer" ähnliche Blogposts nun öfters zu bringen und euch direkter über den aktuellen Stand zu informieren.
+Wir planen solche "Ask the Developer" Blogposts öfter zu veröffentlichen und euch direkter über den aktuellen Stand zu informieren.
 
-Für alle LDAP Fans kann ich auch schonmal einen ähnlichen Post im Stile von "Ask the Developer" ankündigen. Den macht aber der gute Patrick, wenn er so weit ist euch dazu was sagen zu können.
+Für alle LDAP Fans kann ich auch schon mal einen ähnlichen Post im "Ask the Developer" Stil ankündigen. Aber das macht der gute Patrick, wenn er bereit ist, euch etwas dazu zu sagen.
 
-Ansonsten gilt, was immer gilt:
+Ansonsten gilt das, was immer gilt:
 
 Bleibt gesund und happy Mailing!
 

content/posts/whats-up-arm64/index.en.md

@@ -16,56 +16,56 @@ categories: ["What's up?", "News"]
 
 **Moohoo everyone!**
 
-More than a month we have not heard from us and today just like that a shadowdrop as an update.
+It has been more than a month since you heard from us and today we have a shadowdrop as an update.
 
-Since we have some things to discuss and also want to communicate directly in the future, we have come up with a section that we call **What's up?**.
+Since we have a few things to discuss and want to communicate directly in the future, we came up with a section called **What's up?**.
 
-Today we start directly with the first topic, namely **ARM64**:
+Today we start with the first topic, namely **ARM64**:
 
-We had originally announced to make mailcow ARM64 ready by June 2023. Obviously that didn't quite work out. However, we still want to provide this and are continuing to work on it. However, there are a few difficulties in making a faultless transition from mailcow to ARM64.
+Originally we announced to have mailcow ARM64 ready by June 2023. Obviously that didn't work out so well. However, we still want to provide it and are still working on it. However, there are some difficulties to make a smooth transition from mailcow to ARM64.
 
-These are not really noticeable for the main operation, but bother us so much that we leave the whole thing on hold so far.
+These are not really noticeable for the main operation, but they bother us enough to keep the whole thing on hold for now.
 
 > What is it you ask?
 
-Nice that you ask! It's about the Hyperscan library or the implementation of Hyperscan or Vectorscan (as it's called on ARM64) for Rspamd. Said Hyperscan compiles regular regex entries, which are dynamically generated by mailcow and are needed for spam detection. To be more precise, Hyperscan serves as a performance boost here, since the compilation of the regex entries does not have to happen over and over again, but remains compiled.
+Nice of you to ask! It's about the Hyperscan library or the implementation of Hyperscan or Vectorscan (as it's called on ARM64) for Rspamd. Said Hyperscan compiles regular regex entries that are dynamically generated by mailcow and used for spam detection. To be more precise, Hyperscan serves as a performance boost here, since the compilation of the regex entries does not have to be done over and over again, but remains compiled.
 
 > What is the problem?
 
-The problem now is that said Hyperscan (Vectorscan) does not work properly on ARM64 at the current time or the compilation is invalid after a restart because it can no longer load it. But it has to be said that Rspamd just got native ARM64 support with the current version 3.5 and thus can still have some bugs.
+The problem is that the said Hyperscan (Vectorscan) does not work properly on ARM64 at the moment, or the compilation is invalid after a reboot because it can no longer load it. But it has to be said that Rspamd just got native ARM64 support with the current version 3.5 and therefore may still have some bugs.
 
-The main reason why we hold back the ARM64 support (although the actual functionality is already given and has been successfully tested by some testers [THANKS]) is that it comes with some warnings in the console, which can confuse or scare inexperienced users. Also, due to this problem, an equivalent performance cannot be guaranteed.
+The main reason we are holding back the ARM64 support (even though the actual functionality is already there and has been successfully tested by some testers [THANKS]) is that it comes with some warnings in the console that can confuse or scare inexperienced users. Also, due to this issue, equivalent performance cannot be guaranteed.
 
-Additionally there is the fact that some important core components like Dovecot (in particular) have to be compiled by ourselves with the nightly release of ARM64, because the Dovecot team will not offer native ARM64 support and we get the packages in the mailcow stack directly from them and not via the APT repo of Debian like we do with Postfix for example.
+In addition, some important core components like Dovecot (especially) have to be compiled by us with the nightly release of ARM64, because the Dovecot team will not provide native ARM64 support and we get the packages in the mailcow stack directly from them and not via the APT repo of Debian like we do with Postfix for example.
 
-This may have unforeseen consequences at this time, which will need to be clarified in a larger test round.
+This may have unforeseen consequences at this point that need to be clarified in a larger testing round.
 
-We don't want to just "throw in" ARM64 support just so we can say "Hey, mailcow can do ARM64 now, look!!!" but integrate it into the normal release cycle and the normal mailcow architecture so that we can maintain not two repos, but a single repo with the same content for x86 and ARM64.
+We don't want to just "throw in" ARM64 support to say "hey, mailcow can do ARM64 now, look!!!", but integrate it into the normal release cycle and the normal mailcow architecture, so that we can maintain not two repos, but one repo with the same content for x86 and ARM64.
 
-So in the end everyone benefits from it.
+So in the end, everybody benefits.
 
-> What does it mean for ARM64 support?
+> What does this mean for ARM64 support?
 
-We are still working on the support and will really start implementing said changes in the nightly branch soon. However, it will take some time until the whole thing will be moved to the normal stable branch and everyone can use it as they like.
+We are still working on support for ARM64 and will actually start implementing these changes in the nightly branch soon. However, it will take some time before the whole thing is moved to the normal stable branch and everyone can use it as they like.
 
-So in short: We don't want to guarantee a full release this year. We hope for it of course.
+So in short, we don't want to guarantee a full release this year. We hope for it, of course.
 
-Of course we will let you know as soon as there are any news.
+We will of course let you know as soon as there is any news.
 
-Now you know what's going on with ARM64 and why it's stagnating, although it didn't look like that at first.
+Now you know what's going on with ARM64 and why it's stagnating, even though it didn't look that way at first.
 
-Maybe some of you are thinking now:
-> "Because of such a trifle you don't release it?".
+Maybe some of you are thinking:
+> "You're not going to release it for such a small thing?
 
-And probably you won't be completely wrong, but we don't want to do any experiments *fastly*.
+And you're probably not entirely wrong, but we don't want to do any experiments *quickly*.
 
 ---
 
-We plan to publish such "Ask the Developer" like blogposts more often now and inform you more directly about the current state.
+We plan to publish more "Ask the Developer" style blog posts in the future to keep you informed about the current state of the project.
 
-For all LDAP fans I can also announce a similar post in the style of "Ask the Developer". But that will be done by Patrick, when he is ready to tell you something about it.
+For all LDAP fans, I can also announce a similar "Ask the Developer" type post. But that will be done by Patrick when he is ready to tell you something about it.
 
-Otherwise, what always applies:
+Otherwise, the usual applies:
 
 Stay healthy and happy mailing!