Fixed bug #12838: Deactivated fields of $TYPO3_USER_SETTINGS are changed by the modul...
[Packages/TYPO3.CMS.git] / typo3 / sysext / lang / locallang_csh_sysws.xml
1 <?xml version="1.0" encoding="utf-8" standalone="yes" ?>
2 <T3locallang>
3 <meta type="array">
4 <description>CSH for Workspaces table.</description>
5 <type>CSH</type>
6 <csh_table>sys_workspace</csh_table>
7 </meta>
8 <data type="array">
9 <languageKey index="default" type="array">
10 <label index=".description">Defines custom workspaces in TYPO3 which allows for groups of people to work together in a publishing process with draft content. More information about workspaces can be found in the document &quot;Inside TYPO3&quot;.</label>
11 <label index="title.description">Enter the name of the workspace. This value is shown in the workspace selector box in the backend.</label>
12 <label index="description.description">Make a description of the workspace purpose here. This information is shown in the Workspace Manager and should instruct the workspace users about the purpose of the workspace.</label>
13 <label index="adminusers.description">Owners of the workspace are those who are allowed to add members and reviewers to the workspace and pick the page tree starting points etc.</label>
14 <label index="adminusers.details">Owners can also add and delete other owners. If a user is allowed to create workspaces himself he will automatically become the initial owner user of the workspace. They are also the only ones who can eventually publish the workspace content (except general TYPO3 &quot;admin&quot; users) and thus the highest review authority (unless members/reviewers have access to the Live workspace).</label>
15 <label index="members.description">Members can be backend users or groups and will have access to work in the workspace. They cannot publish content (unless they have access to the Live workspace) but only edit it after which they will forward it for approval by a reviewer.</label>
16 <label index="_members.seeAlso">sys_workspace:reviewers</label>
17 <label index="reviewers.description">Content have to pass through reviewers approval before it can finally be published by a workspace owner. Reviewers can be backend users or groups and will have access to the workspace just as members have, but can in addition approve content for final publication.</label>
18 <label index="reviewers.details">In case you need no review layer between editors (normally workspace &quot;members&quot;) and the workspace owners what you simply do is to add all editors as reviewers. This give them access to raise content all the way to the workspace owners. Since content is by default raised from editing to review to publish state it even gives the possibility of informal &quot;four-eye&quot; review where workspace owners can require that content has been raised by action from two different reviewers.</label>
19 <label index="_reviewers.seeAlso">sys_workspace:members</label>
20 <label index="stagechg_notification.description">When the stage of content changes, users in the workspace can receive a notification by email. Only members/reviewers who are attached to the workspace as users and not through their groups will be notified.</label>
21 <label index="stagechg_notification.details">&quot;Notify users on next stage only&quot;: When content is raised from &quot;Editing&quot; to &quot;Review&quot;, reviewers are notified. When content is raised to &quot;Publish&quot;, owners are notified. When content is rejected, members and reviewers are notified. When content is raised from rejected state, members are notified.
22
23 &quot;Notify all users on any change&quot; : All users in workspace are notified regardless of change.</label>
24 <label index="db_mountpoints.description">If one or more DB mounts are specified the page tree of the backend will be locked into these root points during work in the workspace.</label>
25 <label index="db_mountpoints.details">Any DB mount specified here must be inside the DB mount set for the backend user who logs in. If that is not the case the workspace DB mount will simply not be mounted for the user. If no DB mounts are specified for the workspace the users will access the DB mounts of their user profile.</label>
26 <label index="file_mountpoints.description">Filemounts available for workspace users. Please see details for security information!</label>
27 <label index="file_mountpoints.details">IMPORTANT: By default a draft workspace has all filemounts disabled! This is because versioning does not apply to any files edited through filemounts in TYPO3. Hence any access to those files would violate the principle that no content managed in a draft workspace will be live before published.
28 However, for specific projects this violation might be acceptable or necessary and therefore you can add a filemount. This will be forced upon any user in the workspace regardless of his filemounts inherited from his groups and user profile!</label>
29 <label index="publish_time.description">Specify a time of publication of the workspace content.</label>
30 <label index="publish_time.details">The publish and unpublish times are active only if &quot;mod/user/ws/cli/ws_cli.phpsh&quot; is set up as a cronjob running every minute. Example configuration could be &quot;* * * * * /[ABSOLUTE PATH TO TYPO3 SITE]/typo3/mod/user/ws/cli/ws_cli.phpsh&quot;</label>
31 <label index="_publish_time.seeAlso">sys_workspace:unpublish_time</label>
32 <label index="unpublish_time.description">Specify an additional time of (un)publication of the workspace content.</label>
33 <label index="unpublish_time.details">By &quot;additional&quot; is meant that both publishing times are used in a similar way, but if &quot;Publish&quot; is specified it takes precedence over &quot;Unpublish&quot;. Anyway, the point of two publishing times is that workspace content could be swapped in for a limited period and then out again. But notice; for this to work the Swap mode must be set to &quot;Swap-Into-Workspace on Auto-publish&quot;.</label>
34 <label index="_unpublish_time.seeAlso">sys_workspace:publish_time,sys_workspace:swap_modes</label>
35 <label index="freeze.description">If set, no editing is allowed inside workspace.</label>
36 <label index="live_edit.description">If set, records from tables where versioning is not enabled can still be edited &quot;live&quot; inside the workspace.</label>
37 <label index="review_stage_edit.description">If set, records raised to Review stage can still be edited by workspace members. This allows late changes to be made while waiting for the review. Only when the stage is raised to Publish the record is completely locked for editing for members and reviewers.</label>
38 <label index="disable_autocreate.description">If set, records are not automatically created as new versions when edited in the workspace. A new version must be manually created first.</label>
39 <label index="swap_modes.description">Defines modes for publishing as a &quot;swap&quot; action where the online content is moved into the workspace in exchange for the workspace content.</label>
40 <label index="swap_modes.details">By default swapping is allowed. Thereby two versions can be published &quot;in and out&quot; of a workspace multiple times, always substituting each other. If this is not desired, it can be disabled with &quot;Disable Swap-Into-Workspace&quot;.
41 Another mode &quot;Swap-Into-Workspace on Auto-publish&quot; will force the automatic publishing through the cronjob to swap versions. This is necessary to use if you specify both a publish AND un-publish time because otherwise the workspace will be empty after the first publish action!</label>
42 <label index="_swap_modes.seeAlso">sys_workspace:unpublish_time</label>
43 <label index="vtypes.description">Select versioning types you want to disable for workspace editors/reviewers (admin users and owners are not limited).</label>
44 <label index="vtypes.details">&quot;Element&quot; is the most common form of versioning where a single element is versionized solo.
45 &quot;Page&quot; is a versioning type where a page record and child records from specified tables (like &quot;Content Elements&quot; and &quot;Language Overlay Records&quot;) are copied along. This form is more complex but offers flexibility in terms of rearrangement of elements on the page.
46 &quot;Branch&quot; versioning is where a page is versionized and all subpages and content is copied along. This can have quite heavy implications on data duplication and is recommended only in special circumstances.
47
48 More information about versioning types can be read in &quot;Inside TYPO3&quot;</label>
49 <label index="publish_access.description">Refines the rules of publishing</label>
50 <label index="publish_access.details">&quot;Publish only content in publish stage&quot; : Only when content is in publish stage can it be published.
51 &quot;Only workspace owner can publish&quot; : Only the workspace owner can publish the content in the workspace, even if members or reviewers have access to the Live workspace.</label>
52 </languageKey>
53 </data>
54 </T3locallang>