Project Configuration Files

From Lingoport Wiki
Revision as of 16:54, 12 July 2022 by Olibouban (talk | contribs) (config_vcs.properties)
Jump to: navigation, search

Location

Project Configuration Files are copied over to the L10nStreamlining/<group name>/projects/<project name>config folder when a project is created. The original configuration files are located in the ../lingoport/lrm-server-xx/deploy/templates/dir_structure/project folder. These files can be moved to the group or global levels if less granularity is needed.

Project Configuration Files

Under the L10n Streamlining directory (typically <HOME>/Lingoport_Data/L10nStreamlining), each group file structure follows this pattern:

<group_name>
├── config
│   ├── config_due_dates.xml
│   ├── config_l10n_vendor.properties
│   ├── config_lingotek_locale_mapping.properties
│   ├── config_lrm_info.properties
│   ├── config_pseudo_loc.xml
│   ├── config_ws_locale_mapping.properties
│   └── config_ws_locale_projecttype_mapping.properties
└── projects
    └── <project 1>
        ├── config
        │   ├── config_email_recipients.xml
        │   └── config_vcs.properties
        ...

Configuration files can be at the global, group or project level.

Global: <HOME>/Lingoport_Data/L10nStreamlining/config. For more information on the global configuration files, visit the Global Configuration Files page.

Group: <HOME>/Lingoport_Data/L10nStreamlining/<group name>/config. For more information on the group configuration files, visit the Group Configuration Files page.

If there are duplicate files, the project level takes precedence, followed by the group level, and finally the global level.

config_email_recipients.xml

The notification (email) mechanism uses this file to determine which emails are sent to what recipients. This is distinct from the config_email_global.xml file set up in the global directory.

More than one person can be specified in each section.

The file is formatted this way:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<email-recipients>
        <notify-changes>
                <recipient>name1@company.com</recipient>
                <recipient>name2@company.com</recipient>
        </notify-changes>
        <prep-kit>
                <recipient>name@company.com</recipient>
        </prep-kit>
        <import-kit>
                <recipient>name1@company.com</recipient>
                <recipient>name2@company.com</recipient>
        </import-kit>
        <translators>
                <translator>name@company.com</translator>
        </translators>
        <l10nvendoradmins>
                <l10nvendoradmin>name@company.com</l10nvendoradmin>
        </l10nvendoradmins>
</email-recipients>

config_vcs.properties

This file tells what Version Control System to use and the URL of the repository project for check-in and checkout. A typical file looks like this:

# Choices for VCS_TYPE are:
#    - git
#    - svn
#    - tfs
#    ( ftp)
VCS_TYPE=NOTSET

# For GIT
# See http://wiki.lingoport.com/Git
# ----------------------------------
#VCS_GIT_URL=git@github.com:userName/gitProjectName.git
#VCS_GIT_BRANCH=master

# For SVN
# See http://wiki.lingoport.com/SVN
# ----------------------------------
# VCS_SVN_URL=https://svns.company.net/repo/client/trunk/com.company.project.

# For TFS
# See http://wiki.lingoport.com/TFS
# --------------------------------
# VCS_TFS_URL=
# VCS_TFS_URL=http://company:port/tfs/
# TF_SERVER_FOLDER=$/projectX/
# TF_UNIQUE_WORKSPACE_NAME=AUniqueNameGeneratedFromSomeRandomGenerating
## Optional -- associate with a tfs workitem
#   LINGOPORT_WORKITEM_ID=


Please note that this file must be a good Unix file: If the file was copied from a Windows system, dos2unix should first be run on the file. Otherwise the bash scripts may misread the attributes.

After VCS_TYPE is set to a value other than NOTSET, uncomment the corresponding section and provide the correct information for the configuration.

Git Specifics

  • The files to be translated are taken from the VCS_GIT_BRANCH and returned to that same branch. One example would be to on-board a project on 'develop'. Each time a branch is merged back to 'develop', the new source (say, English) resource files are pushed on that branch from the merge. Lingoport detects what files and strings to be sent for translation, and eventually returns the files to that branch.
  • Another typical on-boarding is to have a branch specific for the on-boarding, like a 'translation' branch. In that case, when branches are merged to 'develop', one configuration allows for 'develop' to be automatically merged on to the 'translation' branch. This prevents some files from translation to land directly in the 'develop' branch. In this configuration, a PR to merge from the 'translation' branch on to the 'develop' branch is done by hand after checking the files pushed to the 'translation' branch. To configure the branch 'develop' in this case, another file is used: config_vcs.properties_rebase under the project config directory and contains only one line:
    • VCS_GIT_REBASE_BRANCH=master
  • Lingobot can be used for more sophisticated situation. However, Lingobot duplicates the number of projects and for large repositories, this may lead to performance and disk/ram sizing issues. See About Lingobot

config_l10n_vendor.xml (Optional)

This file is typically located at the Group level. However, if one project in the group needs a different way to move files back and forth with the translation team, it can be overwritten here.

When sending files for translation or getting files back from translation, the system uses config_l10n_vendor.xml. It can be set to use FTP, Lingotek, GlobalLink or Worldserver out of the box. More end points can be added for a custom implementation.

For more information see L10n_Vendors