Just because of a looong but fruitful convo with @Ilia over at Github, may I suggest that because of your “rigid” translation rules/policies, that you articulate and publish them for all?
Things like double dots before or after text, colons with a leading space, formal or informal versions, ellipsis, and so, and so on…
It’d be helpful for potential volunteers to learn expectations upfront and also saves them precious time for necessary rewritings.
Thanks! I could do that!
However, every .auto file already contains everything formatted correctly. The fix may be needed for the language itself, as it was automatically translated. Not to the formatting, as I put an endless amount of effort and time into making this happen automatically when .auto files are generated using language-manager script.
That said, if a phrase ends with .., it means it needs to stay that way. If it starts with .., then it has to be there. If a phrase ends with a ., it shouldn’t be changed, and a dot shouldn’t be added if it wasn’t originally there.
These are the basic rules — nothing fancy or rigid. Besides, it’s always possible to look into the lang/en file to understand how the correct formatting should be.
Double dots are an idiosyncratic usage, and probably should not be formalized. We should be trying to stick to a well-known style guide, and not invent our own. We have quite a few sort of weird idioms, it’d be a negative to formalize those and repeat them forever.
We should be trying to follow something like AP Stylebook, NY Times Manual of Style and Usage, or something along those lines.
Actually, Microsoft has what looks like a quite good style guide, that is free, online, and probably fits better with software and website writing.
Punctuation, specifically, is covered here: Punctuation - Microsoft Style Guide | Microsoft Learn
Well, it is!
This is generally very useful!
Only that, to indicate a pause, we use .. instead of an ellipsis ..., which I think works better for combined lines with phrases, where an ellipsis would be too much.
Example:
Updating Webmin user ...
... done
Updating Webmin user ...
... done
Saving server details ...
... done
Re-loading Webmin ...
... done
I think this case should probably be:
Updating Webmin user...done
The spaces around the ellipsis or double dots are also idiosyncratic (weird).
I don’t really like it, and it will also make errors display weirdly all in a single line without indent!
Since it’s been there for over two decades, I believe we should keep this particular idiosyncrasy.
Even the core team is having opposing opinions how the translations should look like.
For the moment it’s best I stop working on improving the translations and wait for a guideline how to translate.
Happy to crack on once you figured a mutual consent.
No need to wait; you were given detailed explanations about the current format – stick to it. When, and if we decide to change it some time later, it will be easy, as your translations will fall in line accordingly.
Translations aren’t what I’m talking about (sorry for changing the subject). If we change how we use punctuation, it will be automated. No reason to avoid not translating. It won’t be lost in any changes to how we use punctuation.
Okay, understood. Will revert all changes and cope with the weird punctuation even if it’s colliding with my OCD. 
While translating /mailboxes/lang/en I figured inconsistencies. Appreciate if you could comment on the following:
Sort order
Is it allowed to change the order within the translation files and submit a PR eventually? Because some files are quite outdated, lines don’t match and I like to have a line-by-line comparison to make it easier to figure the discrepancies. So, are we allowed to shuffle the order or do we have to follow exact suit?
reply_title=Reply to Email
forward_title=Forward Email
enew_title=Edit Email
reply_headers=Mail headers
Amendments in original EN files
If you amend content, for example you change:
mail_pos=Mails $1 to $2 of $3 in $4
…to:
mail_pos=Messages $1 to $2 of $3 in $4
How to ensure that translators will get notified? I reckon *.AUTO files will only be updated, when new definitions have been added.
Random punctuation
Please explain, why there are random blanks in front of colons:
mail_jump=Jump to page :
view_detach=Detach file:
delete_ereport=Failed to report as spam : $1
What’s the guideline using exclamation marks? Those appear to be set in random way:
index_nousers=No users were found!
index_nousersmail=No users with email were found.
Please explain, why there are random periods:
mail_all=Select all.
mail_deleteall=Delete All
view_aslideshow=Show all images.
view_astext=View as text
search_ecannot=You are not allowed to search this user’s email
search_efield=You must select a search type.
The above examples were extracted from just one file but can be observed throughout the estate.
You can change the order, but the next automated update to the language files in the module will sort them based on the original lang/en.
Well, that key would need to be passed to the language-manager script explicitely to force a re-translation.
The first is either part of regular text or link text, and the other go to the button. It’s not something I personally like, but it is what it is for now. The Authentic theme doesn’t particularly respect these punctuations.
The fundamental requirement is to keep it consistent, which makes future automated changes straightforward.
I honestly don’t know your definition of “consistent” but it is everything but that. Anyway, will keep the weird formatting/punctuation when doing translations.
By the way: When you change/update definitions, those don’t get picked up by the language-manager apparently. I just did a review of at/lang/en which has this line:
index_cdatetime=Current date and time
In the corresponding German language file it shows this:
index_cdate=Aktuelles Datum
index_ctime=Aktuelle Zeit
Do you expect translators to verify (and eventually add) the correct definitions from the source (English) file?
It does when it’s run. However, whoever edited lang/en forgot to re-run it.
Is this something translators or the dev team (you, Joe, Jamie) have to run?
I’d expect anyone making changes to the main lang/en file to run it. I always do, as I’ve automated the process. I also do it in case Jamie forgets, but sometimes I miss some of his changes, and then it gets overlooked.
Thanks for pointing this out though!
Could you briefly describe the ideal approach to tackle translations, please? Via Github PR’s? Within one’s Webmin installation using the translation-manager?
And maybe add it as faq document for other translators who don’t come across this thread.
Although I don’t speak other languages I would like an idea of how it works, so I can add automatic translations to my software 