Closed m4z closed 5 years ago
EmailTemplates
:new_announcement_body
should provide more navigation info (username -> Notification, under "General Settings", de-select "Receive forum newsletters, announcements and important notifications by email.") and/or provide a link to ?action=profile;area=notification;u=1
[fix in #5778]
Profile
:$txt['notify_important_email'] = 'Receive forum newsletters, announcements and important notifications by email.';
(this is the current, correct string, but new_announcement_body
still references an outdated or incorrect version: "Receive forum announcements and important notifications by email."
) [fix in #5778]re 15: this issue is more complex:
- there are many deprecated Headers (pre-
2.1rc2
). Is this language-[in]dependent and needs to be fixed in the english files first, or can I update the German files independently?
To answer my own question: I apparently can't bump the version to 2.1 RC2 in the German version via the LE (and I don't know of any other way). I've tried uploading the file with a bumped version and editing the file via LE, both didn't register as commits.
EmailTemplates
(cont.):
s/to/from/
. [fix in #5778]alert_unapproved_reply_body
: the text does in no way mention that the post is unapproved. Mistake or misnomer? [wontfix/invalid?]{APPYNAME}
+L? [fix in #5778]paid_subscription_reminder_body
, forgot_password_body
); is this valid/common in English? [invalid]register_activate_body
: missing "and" [fix in #5778]register_pending_body
: s/registered with/want to register with/
[fix in #5778]EmailTemplates
(cont.):
notification_reply*body
: s/A reply has been posted to a topic you are watching by {POSTERNAME}/In a topic you are watching, a reply has been posted by {POSTERNAME}/g
? [fix in #5778]s/More (topics|replies) may be posted, but you won\'t receive any more notifications.../You won\'t receive any more notifications (for this (board|topic))? until you (visit|read) (it|the (board|topic))/
[fix in #5778]EmailTemplates
(cont.):
admin_attachments_full_body
: s/it\'s/its/
(https://theoatmeal.com/comics/apostrophe); s/If/if/
? [fix in #5778]new_pm_*body
: missing full stahp. [fix in #5778]new_pm_body_body
: s/was/is/
[invalid/withdrawn]karlbenson1_body
: missing full storp after 2nd "didn't". [fix in #5778]karlbenson2_body
: something, maybe a (semi)colon, is missing between "ever" and "cloudy", no? [fix in #5778]ManageSettings
:
languages_download_copy
: technically this might be copying, but for the admin, "overwrite" or "install" might be clearer. [fix in #5778]*Stats
: why "daily"? [fix in #5778]ManageSettings
(cont.):
allow_disableAnnounce
: what does this actually do? the 2.0 german translation hints that this doesn't disable announcements, but (mail?) notifications of the announcements. [fix in #5778]onlineEnable
: s/online\/offline/online status/
[(changed) fix in #5778]s/url/URL/g
[fix in #5778]ManageSettings
(cont.):
setting_password_strength_{medium,high}
: what does the code actually do? [invalid/wontfix]ManageSettings
(cont.):
recaptcha_configure_desc
: s/> G/>G/
? [fix in #5778]signature_settings_warning
: Which process? The described default behavior or the special apply-to-all stuff? [fix in #5778]custom_edit_profile_desc
: s/edited in/added to/
[fix in #5778]ManageSettings
(cont.):
languages_max_inputs_warning
should directly reference (probably) index:$txt['save']
[wontfix], and s/reloads/was reloaded/
or so. [fix in #5778]ManagePaid
:
paid_currency_symbol_desc
: missing full stop. [fix in #5778]paid_note
seems incomplete/misleading, only references PayPal but not WorldPay, Nochex, Authorize.Net, 2co.com. [invalid (fixed by removing the strings for nonexistent providers)]paid_confirm_*
and paid_*_order
could be templates/parameterized. [invalid (because 22b)]paid_invalid_duration_[WM]
: missing full stop. [fix in #5778]pending_payments_desc
should use pending_payments_accept
[wontfix]ManageSettings
(cont.):
languages_download_info
should use languages_download_{exists,exists_same,exists_different}
, yes
/no
. [wontfix]languages_download_info
: s#Not Writable#$languages_download_writable: $yes/$no#
[wontfix]ModerationCenter
:
mc_reportedp_ignore_confirm
: "ignore and ignore" [fix in #5778]mc_memberreport_*
: s/this member/this profile/
? [fix in #5778]report_action_open
: +"ed" [fix in #5778]mc_warning_template_body_desc
: missing formatting [wontfix?]; s/Member Name/Account Name/
? [wontfix?]mc_warning_template_error_no_title
: s/title/a title/
[fix in #5778]mc_reportedm_ignore_confirm
: unclear/, rephrase more like mc_reportedp_ignore_confirm
? [fix in #5778]ManagePermissions
:
permissions_boards_desc
should use permissions_boards_all
directly. [wontfix]permissionhelp_profile_*
: pluralize members everywhere? [fix in #5778]permissionhelp_view_stats
: use index*.php
:more_stats
directly? [wontfix]permissionhelp_who_view
: use index*.php
:online_users
directly [wontfix] (also: redundant Stats
:users_online
)? [wontfix?]ManagePermissions
(cont.):
permissionhelp_search_posts
:index
:search
directly. [wontfix]permissionhelp_pm_send
should use permissionname_pm_read
directly. [wontfix]permissionhelp_calendar_view
Admin
:layout_controls
and Admin
:manage_calendar
directly [wontfix]permissionhelp_edit_news
: s/enabled/enable/
[fix in #5778]permissionhelp_moderate_forum
: what does "tracking the (hidden) online status" mean? That the O.S. hiding doesn't apply to moderators? [fix in #5778]ManagePermissions
(cont.):
permissionhelp_lock
: stray newline [fix in #5778]ManagePermissions
(cont.):
permissionhelp_view_attachments
should use Admin
:attachments_avatars
directly. [wontfix]ManagePermissions
(cont.):
permission_by_board_desc
should use permissions_profile_edit
directly [wontfix]permission_disable_*_warning
should be phrased similarly(?) [fix in #5778]I'm currently diving through this and I will be posting thoughts as I pass through issues.
I'm currently diving through this and I will be posting thoughts as I pass through issues.
- It's [...] less than %1$d seconds ago. The %1$d is used to pass an argument through the sprintf() function, that will add said value to the text string.
My main point was about readability/intelligibility of the strings. The user probably doesn't care about sub-second precision, so s/less than//g
is probably fine for them, much easier to read and somewhat closer to the truth: I still don't believe the current phrasing to be a good one, because IIUC it is incorrect "half of the time" (for x.0[...]
to x.49[...]
, and only correct for x.5[...]
to x.9[...]
).
- d) I don't understand what you're trying to say.
Oh my, so did I, should've been more verbose the first time. I think I had two points:
- g) More confusing, in my opinion.
Yeah, you're probably right, the current string is much easier to understand. Mine is technically more correct (and was the only way for me to force the error), but transitivity and all.
- Probably someone forgot to change those when releasing RC2. I will have that in mind for future releases, but it's not really important. Also, I agree that you've probably been working with outdated strings, but you have to take into account that this version is still under development. Many changes are expected and non definitive. To update the files, one of the Localizers has to do it manually. I will do it once we make a new release.
Yeah, remember I am (or was) a new translator, and it took me a while (as in 8+ weeks) to figure out that
So some items, and this item in particular, I'm also writing down (highlighting, if you will) so that somebody more involved in these processes can see there are issues/intransparencies/counter-intuitive weirdnesses with them, and improve the situation. (And I'm also quite forgetful, so I'm also writing them down so that myself and other noobs (can, at least) know about these issues.)
- a) Where's 20 a)??
It was two comments up, above some other 19-ish items. I moved it down now, a little less chaos.
More comments tomorrow...
My main point was about readability/intelligibility of the strings. The user probably doesn't care about sub-second precision, so
s/less than//g
is probably fine for them, much easier to read and somewhat closer to the truth: I still don't believe the current phrasing to be a good one, because IIUC it is incorrect "half of the time" (forx.0[...]
tox.49[...]
, and only correct forx.5[...]
tox.9[...]
).
I believe readability is good with this form. Also I haven't heard any translator complain about the actual form of the string, so I believe the best option is to leave it as it is.
Oh my, so did I, should've been more verbose the first time. I think I had two points:
- The first sentence basically says "Theme already installed [in this exact version], or installed in an older version", which is kind of redundant and could be phrased better if it was standing alone (f.e. like "Theme already installed in a deprecated or the same version."). However, since we're displaying the exact versions in the second sentence, we don't need to make that distinction, the user will directly see which of the two cases it is, or we could merge them in a single sentence.
- The second sentence of the string would IMAO also be more readable if it was the other way around (I also generally like to have "the old versions before the new"): "You already have version X of this theme installed, and you are/were trying to install version Y."
I'm in favour of making sentences as simple as we can, but we need to have in mind that this software is used by a very wide range of people. Some users even struggle to install a theme and in this particular case I'm in favour of leaving the sentence as it is. As for the second sentence, makes sense. Will be addressed in the next commit.
Yeah, remember I am (or was) a new translator, and it took me a while (as in 8+ weeks) to figure out that
- the reason the english files and my translated files showed outdated versions in my forum wasn't somehow my fault, and that
- I can't update these versions myself when working on my translations, and
- localizers make mistakes too and forget to bump the version even though their commit messages say otherwise, and
- github has never versions of the language files than the language editor that I was told to use by all the tutorials...
So some items, and this item in particular, I'm also writing down (highlighting, if you will) so that somebody more involved in these processes can see there are issues/intransparencies/counter-intuitive weirdnesses with them, and improve the situation. (And I'm also quite forgetful, so I'm also writing them down so that myself and other noobs (can, at least) know about these issues.)
Do mind we're using a very outdated and deprecated translation software. It was partially fixed a few months ago by Sesquipedalian but it's still limited. We've been trying to move to another platform (Crowdin in particular) and it not much left to go to complete the move. That's why I haven't updated any of the tutorials and that's why everything is (still) messy.
- a) Where's 20 a)??
It was two comments up, above some other 19-ish items. I moved it down now, a little less chaos.
It will be addressed in the next commit.
- b) [directly include variables like button strings in other strings] I don't agree. I think it's good as it is.
Ugh, this can of worms up front...
Coming at this from the translation angle, this, and other strings like it, were some of the most tedious to translate. Most strings can be translated without "context" and only some knowledge of SMF. But for strings A that use other strings B verbatim, I have to search the English file for the string B, hoping to find the correct variable name (some of these references are cross-file and cost me literally minutes to find, see f.e. 20. i)
, 24. c)
, 24. d1)
, 24. d2)
, 24. f)
), then look up the translation of B in the German file and keep that translation synchronized with A. For some strings, they're so hard to find with my limited SMF skills that I had to look them up with my browser in my forum installation, then look at the code to hopefuly somewhat understand what is happening, find the correct string, and then look it up as above. I could only do that because I can read a bit of PHP; for a non-IT translator this is next to impossible. I found many of these cases because the current translation was inconsistent (f.e. a german help text said to click a "Continue" button, but there only was a button "Next"; help texts describing tables used different translations of terms than the actual tables, ...). (And some of these strings I can never even see live, for example the upgrade stuff, or stuff for different databases or features I can't or don't want to use.) It is really tedious and time-consuming to guesstimate which string might be referenced.
If these strings were PHP-included, I wouldn't have to worry about all this, and there'd be a lot less duplication of "SMF term" strings. (Sure, it'd be one more thing to explain to non-IT translators in the tutorial(s)...)
- e) I believe for end-users with no knowledge of relative or abslute paths it's a really good description.
Ok, you're right. I still think the second issue is a bit confusing, but I have no solution right now. I'll probably re-think about it on another day.
- g) It means, when selected, you'll backup the tables of your current database with the prefix "backupsmf". If you run upgrade.php, you'll see it and it's pretty clear.
Ah, maybe s/B/If selected, b/
&& (s/the/this/
or s/the/the following/
)?
- Quite unsure about that.
I'm quite sure about it, c.f. here ("Never use a hyphen in place of an en dash or an em dash.")/here, here, here/here, here/here.
- Agreed, but I don't think we really need all of those changes at this stage.
Ack.
- c) I believe it's obvious.
Maybe, I wasn't yet able to get my mail notifications to work.
- e) I believe it's valid and common since you're starting a new line.
The internet seems to agree with you.
- h) Yeah... We'll leave it for another time :P
😞
More comments... maybe Tuesday evening (CET)? 😑
Ugh, this can of worms up front... Coming at this from the translation angle, this, and other strings like it, were some of the most tedious to translate. Most strings can be translated without "context" and only some knowledge of SMF. But for strings A that use other strings B verbatim, I have to search the English file for the string B, hoping to find the correct variable name (some of these references are cross-file and cost me literally minutes to find, see f.e.
20. i)
,24. c)
,24. d1)
,24. d2)
,24. f)
), then look up the translation of B in the German file and keep that translation synchronized with A. For some strings, they're so hard to find with my limited SMF skills that I had to look them up with my browser in my forum installation, then look at the code to hopefuly somewhat understand what is happening, find the correct string, and then look it up as above. I could only do that because I can read a bit of PHP; for a non-IT translator this is next to impossible. I found many of these cases because the current translation was inconsistent (f.e. a german help text said to click a "Continue" button, but there only was a button "Next"; help texts describing tables used different translations of terms than the actual tables, ...). (And some of these strings I can never even see live, for example the upgrade stuff, or stuff for different databases or features I can't or don't want to use.) It is really tedious and time-consuming to guesstimate which string might be referenced. If these strings were PHP-included, I wouldn't have to worry about all this, and there'd be a lot less duplication of "SMF term" strings. (Sure, it'd be one more thing to explain to non-IT translators in the tutorial(s)...)
So, you're saying that:
$txt['string_one'] = '[...]'; [...] $txt['string_two'] = 'First part' . $txt['string_one'] . 'second part';
Will be better for translating than this one?
$txt['string_one'] = '[...]'; [...] $txt['string_two'] = 'First part (implicit string one) second part';
Sorry but as a translator I highly disagree with this. We need and must provide the full sentence so that non-experencied SMF/PHP users can translate the software without too much troubles. I know that without including the strings using PHP the text strings will have duplicates and will become less consisten in general, but that's something we have to assume.
Ah, maybe
s/B/If selected, b/
&& (s/the/this/
ors/the/the following/
)?
As it's a checkbox that affects the immediate behaviour of the upgrade process we cannot use "If selected". Perhaps we could change it to something like: Perform a tables backup in your database with the prefix
. Do you like that?
I'm quite sure about it, c.f. here ("Never use a hyphen in place of an en dash or an em dash.")/here, here, here/here, here/here.
In Spain we barely use hyphens, en dash nor em dash and my english knowledge is not that high to properly judge this suggestion.
Sorry but as a translator I highly disagree with this. We need and must provide the full sentence so that non-experencied SMF/PHP users can translate the software without too much troubles. I know that without including the strings using PHP the text strings will have duplicates and will become less consisten in general, but that's something we have to assume.
I agree
I've commented here and there in the referenced issues, and started adding annotations above, because I've totally lost track... (Thanks for your time and effort!)
So, you're saying that:
$txt['string_one'] = '[...]'; [...] $txt['string_two'] = 'First part' . $txt['string_one'] . 'second part';
Will be better for translating than this one?
$txt['string_one'] = '[...]'; [...] $txt['string_two'] = 'First part (implicit string one) second part';
Yes, with ∞-1 exclamation points! As I said before, right now it's (sometimes) very time-consuming to even find what is referenced. I hate the current situation, where for some single strings I need more time to translate them than for 30 others combined. (I don't know anything about Crowdin, maybe it can be told to expand such variables before showing the strings to the translators? Would kinda be a best of both worlds scenario.) But I'll now shut up about it, apparently nobody else has an issue with it. 😭
Ah, maybe
s/B/If selected, b/
&& (s/the/this/
ors/the/the following/
)?As it's a checkbox that affects the immediate behaviour of the upgrade process we cannot use "If selected". Perhaps we could change it to something like:
Perform a tables backup in your database with the prefix
. Do you like that?
👍
I'm quite sure about it, c.f. here ("Never use a hyphen in place of an en dash or an em dash.")/here, here, here/here, here/here.
In Spain we barely use hyphens, en dash nor em dash and my english knowledge is not that high to properly judge this suggestion.
Yeah, I'll try to do it myself. ;)
More annotations, comments, reviews (hopefully) tomorrow.
20. b) Umm, that's how it's coded?
Yeah, my point was that it isn't all daily (or rather, hardly anything at all), especially in ?action=stats
, i.e. when displaying the stats (which, for most users, is "stats").
I had browsed the stats before, and really asked myself, "Why TF does this string call it daily stats?"
c) Announcements are sent via email, so I guess that's what it means. Perhaps change it to "Allow users to disable mail announcements"?.
👍
e) It's the required strength of the password in the register page. As for the code, the medium can't contain the username you're trying to register with and the high checks for different types of characters being used in the password (I guess numbers, letter, special characters...).
Interesting, no length checks at all? Pre-y2k code? 😬 🙊
g) When you change any of the settings of the signatures, you would like to apply them to the existing signatures. That's the process.
Hmm, s/Run the process now/Apply now/
(or "Apply them now", or even "Do it now")?
h) No, it's good that way. It means in what place of your profile you will be able to edit the profile field.
Yeah, the string is describing the user view after the field has been added, but the person viewing this string (under Configuration → Features and Options → Profile Fields→ "Modify" or "New Field") is the admin, who is adding the field. 🙄 😇 (If you still want to stick with "edit", I'd very much prefer something more verbose like "Section of the profile the users will (be able to|have to)? edit this in.
")
i) Not quite sure about that one. I'll leave it as it its, for now.
The first (include) part, I can understand, we discussed this. But what about the second part, aren't you as annoyed by the tense as I am? It sounds like the user is supposed to start clicking once the reloading begins, before the page has even finished reloading. 😉
- d) [missing full stops] Where?
paid_invalid_duration_[DY]
have a final full stop, paid_invalid_duration_[WM]
don't.
- b) Is it confusing now?
I haven't looked at the code, but from the strings and Moderation Center layout I assume it separates profile reports (called member reports in the variable names and MC menu) from post reports.
My problem with the term "member" is that in both cases, you report something that the member created, either a text or picture in the profile or a text or picture in a post; essentially both are member reports at the core.
So, in the Moderation Center section "Reported Members" I would also expect to find all users who created posts that have been reported, but from the description, I assume this only shows profile reports: "Allows you to view a list of all users whose profiles have been reported
"
(This point is maybe worth its own issue, to get the reporting vocabulary in sync across all files.)
- d) The tag is {MEMBER} so I'll leave it like that
Yeah, what nags me is the unclear reference to either the account/profile or the real name of the member; that's what this was about.
- h) You can hide your online status as a member. That option's purpose is for moderators to view users's status even if they hide it.
Ok, I suggest s/(hidden) online status/online status (even if hidden)/
then. 😉
More... later.
Yeah, my point was that it isn't all daily (or rather, hardly anything at all), especially in
?action=stats
, i.e. when displaying the stats (which, for most users, is "stats").
- In the forum stats, there are some totals averaged to daily values up top, but everything else is totals, top 10, top n, and monthly and weekly totals.
- In the user stats view, there isn't anything daily (except the activity by hours distribution, if you want to count that), only totals and percentage distributions.
I had browsed the stats before, and really asked myself, "Why TF does this string call it daily stats?"
Suggestion:
$txt['trackStats'] = 'Track statistics';
$txt['hitStats'] = 'Track daily page views (statistics tracking must be enabled)';
|| $txt['hitStats'] = 'Track daily page views (Track statistics must be enabled)';
Do you like that?
👍
It will be addressed in the next commit.
Interesting, no length checks at all? Pre-y2k code? 😬 🙊
No clue actually. Would have to dig into the code to confirm, but probably yes. Maybe 3-4 chars long.
Hmm,
s/Run the process now/Apply now/
(or "Apply them now", or even "Do it now")?
Do you mind if I just: Apply changes now
to make it a little bit more clear?
Yeah, the string is describing the user view after the field has been added, but the person viewing this string (under Configuration → Features and Options → Profile Fields→ "Modify" or "New Field") is the admin, who is adding the field. 🙄 😇 (If you still want to stick with "edit", I'd very much prefer something more verbose like "
Section of the profile the users will (be able to|have to)? edit this in.
")
It will be addressed in the next commit.
The first (include) part, I can understand, we discussed this. But what about the second part, aren't you as annoyed by the tense as I am? It sounds like the user is supposed to start clicking once the reloading begins, before the page has even finished reloading. 😉
Suggestion: $txt['languages_max_inputs_warning'] = 'You can only save %1$s edits at a time. Please click the Save button now, and then continue editing once this page reloads.';
Does it look better?
paid_invalid_duration_[DY]
have a final full stop,paid_invalid_duration_[WM]
don't.
It will be addressed in the next commit.
I haven't looked at the code, but from the strings and Moderation Center layout I assume it separates profile reports (called member reports in the variable names and MC menu) from post reports.
My problem with the term "member" is that in both cases, you report something that the member created, either a text or picture in the profile or a text or picture in a post; essentially both are member reports at the core. So, in the Moderation Center section "Reported Members" I would also expect to find all users who created posts that have been reported, but from the description, I assume this only shows profile reports: "
Allows you to view a list of all users whose profiles have been reported
"(This point is maybe worth its own issue, to get the reporting vocabulary in sync across all files.)
It will be addressed in the next commit.
Ok, I suggest
s/(hidden) online status/online status (even if hidden)/
then. 😉
It will be addressed in the next commit.
More... later.
Gamsahabnida! (Thanks in Korean)
Suggestion:
$txt['trackStats'] = 'Track statistics';
$txt['hitStats'] = 'Track daily page views (statistics tracking must be enabled)';
||$txt['hitStats'] = 'Track daily page views (Track statistics must be enabled)';
👍 (I prefer the first option on hitStats
, or the second with s/Track statistics/"&"/
Interesting, no length checks at all? Pre-y2k code? 😬 🙊
No clue actually. Would have to dig into the code to confirm, but probably yes. Maybe 3-4 chars long.
🤦♂ 😆
Hmm,
s/Run the process now/Apply now/
(or "Apply them now", or even "Do it now")?Do you mind if I just:
Apply changes now
to make it a little bit more clear?
Not at all, in fact it's better than what I suggested (and you already went ahead and fixed it -- I love you, man 👊).
Yeah, the string is describing the user view after the field has been added, but the person viewing this string (under Configuration → Features and Options → Profile Fields→ "Modify" or "New Field") is the admin, who is adding the field. 🙄 😇 (If you still want to stick with "edit", I'd very much prefer something more verbose like "
Section of the profile the users will (be able to|have to)? edit this in.
")It will be addressed in the next commit.
🦄 🌈 💟
The first (include) part, I can understand, we discussed this. But what about the second part, aren't you as annoyed by the tense as I am? It sounds like the user is supposed to start clicking once the reloading begins, before the page has even finished reloading. 😉
Suggestion:
$txt['languages_max_inputs_warning'] = 'You can only save %1$s edits at a time. Please click the Save button now, and then continue editing once this page reloads.';
Does it look better?
Nah, it still talks about the present and sounds like I am supposed to keep editing during the reload. I'm still in favor of "was reloaded" or "has reloaded", or maybe even `s/editing .+/editing afterwards./" or "after the reload" or "when the page finished reloading"... Something that describes a finished reload.
More... later.
Gamsahabnida! (Thanks in Korean)
👍s and ❤️s for all the fixes. (PS: My girlfriend, who speaks (non-native) Korean, says your spelling is strange, at least a trailing t is missing. 😉)
👍 (I prefer the first option on
hitStats
, or the second withs/Track statistics/"&"/
It will be addressed in the next commit
Nah, it still talks about the present and sounds like I am supposed to keep editing during the reload. I'm still in favor of "was reloaded" or "has reloaded", or maybe even `s/editing .+/editing afterwards./" or "after the reload" or "when the page finished reloading"... Something that describes a finished reload.
Are you ok with [...] once this page has reloaded.
?
👍s and ❤️s for all the fixes. (PS: My girlfriend, who speaks (non-native) Korean, says your spelling is strange, at least a trailing t is missing. 😉)
Ah, who understands Korean? :P
Are you ok with
[...] once this page has reloaded.
?
👍
👍s and ❤️s for all the fixes. (PS: My girlfriend, who speaks (non-native) Korean, says your spelling is strange, at least a trailing t is missing. 😉)
Ah, who understands Korean? :P
Not this one.
Anymore thoughts on this @m4z?
Lemme check; in fact I was waiting for more commits. You didn't yet comment on or fix:
14. e)
16. h)
19. f)
19. i)
19. j)
19. k)
19. m)
19. n)
19. o)
19. p)
And you said you were going to fix 24. h)
but didn't yet.
Was any of this on purpose or did you overlook any of them? 😉 😇
Besides this I've lost track and I would say let's keep it at that. Anything else I will address another day. Thanks again for all the work; the next issues I'll hopefully be able to PR myself. ❤️ 🍰 🦄
14. e)
What's wrong with that one?16. h)
Will be addressed in the next commit19. f)
Where?19. i)
Will be addressed in the next commit19. j)
Will be addressed in the next commit19. k)
Will be addressed in the next commit19. m)
Will be addressed in the next commit19. n)
I'll leave was to concordate with sent19. o)
Will be addressed in the next commit19. o)
Will be addressed in the next commit24. h)
Ah, I'm pretty sure I did change that one... Maybe I didn't save changes in the editor before committing.Thanks once again!
14. e)
What's wrong with that one?
You need to enter a "valid email (address)" or an "email (address) in a valid format", but "enter a valid email (address) format" sounds wrong to me, like I'm supposed to enter a regex pattern for matching mail addresses. 😉
19. f)
Where?
please visit {ACTIVATIONLINKWITHOUTCODE} *and* use
19. i)
Will be addressed in the next commit
You only changed 1/3 variables (notification_reply_body
, but not notification_reply_body(_once)?_body
). 😇
19. j)
Will be addressed in the next commit
You "forgot" notify_boards_once(_body)?_body
because the pattern I provided was incorrect (it lacked an additional "(email)?
"
19. k)
Will be addressed in the next commit
You fixed the "its" but not the "if". 😇
19. m)
Will be addressed in the next commit
You forgot new_pm_tolist_body
and new_pm_body_tolist_body
. 😇
19. n)
I'll leave was to concordate with sent
Yeah you're probably right.
Thanks once again!
Thank you!
14. e)
What's wrong with that one?You need to enter a "valid email (address)" or an "email (address) in a valid format", but "enter a valid email (address) format" sounds wrong to me, like I'm supposed to enter a regex pattern for matching mail addresses. 😉
Alrighty, fixed in the next (and hopefully last) commit ;)
please visit {ACTIVATIONLINKWITHOUTCODE} *and* use
That's already fixed since https://github.com/SimpleMachines/SMF2.1/pull/5778/commits/95ea69650e5c8709114b725640486cd71d61732d
You only changed 1/3 variables (
notification_reply_body
, but notnotification_reply_body(_once)?_body
). 😇
In the next commit!
You "forgot"
notify_boards_once(_body)?_body
because the pattern I provided was incorrect (it lacked an additional "(email)?
"
Err yes... Sorry, I sometimes get lost through your syntax!
You fixed the "its" but not the "if". 😇
I didn't even see it lol
You forgot
new_pm_tolist_body
andnew_pm_body_tolist_body
. 😇
Roger that, chief!
14. e)
What's wrong with that one?You need to enter a "valid email (address)" or an "email (address) in a valid format", but "enter a valid email (address) format" sounds wrong to me, like I'm supposed to enter a regex pattern for matching mail addresses. wink
Alrighty, fixed in the next (and hopefully last) commit ;)
LGTM. :+1:
please visit {ACTIVATIONLINKWITHOUTCODE} *and* use
That's already fixed since 95ea696
Ugh, I guess I slept through that one… My bad.
You "forgot"
notify_boards_once(_body)?_body
because the pattern I provided was incorrect (it lacked an additional "(email)?
"Err yes... Sorry, I sometimes get lost through your syntax!
I never meant for anybody but myself to have to understand it. :innocent:
You fixed the "its" but not the "if". innocent
I didn't even see it lol
Yeah, my bad for making a list and then sometimes cramming multiple things into a single item. :blush:
You forgot
new_pm_tolist_body
andnew_pm_body_tolist_body
. innocentRoger that, chief!
Thanks!
PS: I don't see a fix for 23. b)
("member" vs. "profile" in mc_memberreport_*
), did this also fall through the cracks?
PS: I don't see a fix for
23. b)
("member" vs. "profile" inmc_memberreport_*
), did this also fall through the cracks?
The demons are playing mind games with me... Fixed now 🚀
Damn, I missed #5635-#5638 up there. They're basically already PRed, but had a trailing newline. Could you include those, too? :disappointed:
Sorry and thanks!
D-Done 😄
Gnah, communication, so sorry. I meant #5635 to #5638 (#5635, #5636, #5637, #5638) :sweat_smile:
@m4z Sorry, I was at uni and couldn't do the changes there. If you're going to submit more PRs, please address those issues there 💛
Will do. (I was at work and often can't react to private mail quickly, or else I'd have responded quicker.) 💚
Dumping my rather draft-y braindump-y collection of issues here, since in #5634, Sesquipedalian asked me to do it. I'm translating my own comments without context here, so they might not be clear (I'll improve them later, if necessary). I will roll this into a PR in a couple of days or weeks.
I can't figure out how to nest numbered lists; behold, this is gonna be a mess…
Errors
, say stuff like "less than x seconds ago". Is this some weird kind of rounding down in the code, or just a mistake in the text? [wontfix]Errors[…].php
:too_many_groups
: "please remove some [from your selection]", otherwise might trigger over-eager users to delete the actual groups (don't make me have to think) [fix in #5778]post_upload_error
: "is can be caused" [fix in #5778]search_invalid_weights
: "should be configure to be" [fix in #5778]package_get_error_theme_no_new_version
: turn logic around [(updated) fix in #5778]profile_error_custom_field_mail_fail
: -"format" [fix in #5778]loadavg_userstats_disabled
: switch sentence order. [fix in #5778]mboards_parent_own_child_error
: change to "You can not make a board into a sub-board of one of its own sub-boards."(?) [invalid/withdrawn]s/Json/JSON/g
[fix in #5778]2.1rc2
). Is this language-dependent and needs to be fixed in the english files first, or can I update the German files independently? [manual update on release (of rc3 or stable 2.1?)]Install[…].php
:db_settings_prefix_info
: s/value/key or option/ [fix in #5778]db_populate_info2
: should directly useinstall_settings_proceed
(if that assumed reference is correct), and generally all these String-Quote-References should (code-)use the original string; this is a defused version of my suggestion in the "Department of Redundany Department" thread for only verbatim quotes [wontfix]error_session_missing
: wtf? [fix in #5778]$txt['error_session_missing'] = 'The installer was unable to detect session support in your server\'s installation of PHP. Please ask your host to ensure that PHP was compiled with session support (which in fact is the PHP default, meaning your host currently has explicitly disabled it.)';
error_username_too_long
:s/25/26/
or'Username may only be up to 25 characters long.'
seems to more accurately reflect the code [fix in #5778]ftp_path_help
is unclear. It's missing the hint to the user that the path is relative, and the text seems to describe at least two different paths, the FTP main path and the SMF-Path. [maybe later]upgrade_areyouready
: use (code-)reference to the Continue-Variable. [wontfix]upgrade_backup_table
attempt a forum upgrade and check… something? (probably under what conditions this string is shown, or whether it is accurate, or what the exact meaning is so I can actually translate it well). [fix in #5778]upgrade_error_script_js
: Texts like this refer to Tools which probably have Deeplinks (in this case, yes: https://download.simplemachines.org/?tools), but they just link to the main site. Is this on purpose (maybe because they might change over the years; but then they could still be grepped for and updated)? Why make the user search, this will probably keep users from taking this route. [fix in #5778]upgrade_time_ago_{hms,ms,s}
: -"ago" in the text [fix in #5778]upgrade_repondtime
: Variablename +s [fix in #5778]