Need context for „Enable site mentioning” in
Is it „Enable the overall Mentioning feature in this site” or „Enable mentions of (other) sites”? I would rather bet on the former, but better safe than sorry...
Its the master setting to enable the mentioning feature on your site. It enables the @ mention usage in posts, getting a mention notification when one of your posts is liked, etc etc
Thanks, that's what I thought. Then maybe it should be "Enable user mentioning"...
Another one: If a member's warning level gets over "Member Muting" level, he can no longer post. But he can still send PMs, right? I think this bit of info should be in the help text of the warning level, just to make it clear to the admins that there's still a channel open for discussions:
Key:
mute_enable
Size:
29 words
Context:
None
Resource:
Help.english.php
I have no idea where and in which context should this be used. (I have a test ElkArte forum up and running, but I can't find it's page)
Key:
moderator_why_missing
Size:
4 words
Context:
None
Resource:
Profile.english.php
What's the difference between "request_group" and "request_group_membership"?
It's in profile settings, under dropdown list where you can select groups for user.
There is no moderator group in list, because moderators are added in board settings, specifically for boards.
Key
request_group is used inside button,
request_group_membership is used in next step (after choosing group with
request_group)
request_group should be shorter, because its on button and longer text strings can look bad on buttons.
Hope this helps, if you need more help just ask :)
Thenks a bunch, OF COURSE it helps!!
If you want, you should be able to add notes to the entries at transifex that may help others with similar doubts.
I did some in the past, I'm not sure if it requires some special permission though. If so, just tell me and I'll try to understand what is needed. ;D
No special permission needed for submitting issues (I think currently there are 3 outstanding), but I don't think they're visible enough. Getting to them isn't quite as straightforward as should be (see attachment). Besides, any translator is pretty much bound to cast an eye around here :).
Granted, an issue created in Transifex might signal there's a problem - and possibly the solution for it - but, as I said, the interface forces them to somewhat "fly under the radar" of both translators and project managers. I think I'll do it both ways: marking an issue in Transifex and asking here. There's a good chance that "non-translating" members (with no interest in watching over Transifex for issues) might shed a light on the problem, thus relieving the "coding side" of ElkArte of part of this burden...
Is this approach OK or should things be kept separate?
My idea was more the "instructions" are you can see in the translation interface (see attachment) or the "comments" tab in the bottom-right corner.
Unfortunately
Instructions are NOT editable by either
Coordinators or (presumably)
Translators. The best we can do is add
Comments and mark them as
Issues (see pic). Alas, comments can be both
Deleted and/or
Solved. Furthermore, their tab is most of the time „out of focus”, as one generally translates having either
Suggestions or
History tabs selected. These two are reasons which partially defeat the use of
Issues as „heads-up” info conveyers.
One MO that could prove useful would be copying the
Issue solutions to
Instructions, but that could only be carried on by those with the right permissions.
P.S. Actually, there's on more useful MO, which I've grown quite fond of: using Notepad++ with the NppFTP Plug-in to edit the live files on a mock-up test forum and navigating/refreshing said forum to see the effects of my edits in near-real-time and in native context; when I'm happy with the results, I upload the edited files to Transifex ;).
Ohhh... okay. :-\
Maybe it's something that can be "given" easily, I have to check. :)
Anyway, yep, the "translate the file and upload it approach" is a valid one as well! :D