Projects:Translation PO Merge/Functional Specifications
Contents |
Translation PO Merge - Functional Specifications
Overview
This project is to provide a tool that will enable the merging of two PO files into a single instance. This instance should be compatible with the Openbravo2PO tool and open source PO editing tools.
Purpose
This project has come from a community requirement to enable different contributors to merge separate translation projects into a single collaborative project. This requires being able to merge the current translation files into a single instance which then they can use to continue their work and refine towards a common translation release.
Scope
This specification covers the merge process only from to two PO files into a single PO file.
References
Design Considerations
Assumptions
- Both input files will be specified during the running of the application using full filenames.
- The assumption is being made that the PO files are of reasonable standard in terms of standardised format.
- Output will be in the same format that will be consistent with that provided by the Openbravo2PO file.
Dependencies
- The enhanced Openbravo2PO tool is available for use.
- All file formats should be in the UTF-8 format.
Constraints
- This functional specification has been prepared without previously viewing the files currently being used by the community members.
- Due to a target to release the translation at the end of June this tool is required to be functional by June the 13th.
- Due to time constraints the deployment and use of this tool will be through a build.xml ANT task. This task will take the individual files which are to be merged.
Glossary
- PO - Portable Object
- mesgId - Original string used for defining the translation
- mesgStr - the translated string which will be imported into the Openbravo application and used as the translation text
- XML - file format used for importing and exporting translation data within the Openbravo framework
Functional Requirements
User roles & profiles
Business process definition
User stories
The following table shows a break down of the user stories identified to complete the functional specification within this document.
Structural Development Phase
| ref | title | func spec ref | description | priority | dependencies | status |
|---|---|---|---|---|---|---|
| 1 | Merge two files | MTRL1 | The system will allow the user to define two .po files which will be merged in to a single .po file | Critical | - | done |
| 2 | Create unique rows | MTRL2 | The system will ensure that all unique translations between the files are created in the merge file in correct format that will allow the user to import them to the Openbravo2PO tool | Critical | - | done |
| 3 | Highlight conflicting translations | MTRL3 | The system create a single entry in the merge file for translations that are present in both import files. These conflicts will be easily searchable for the user to identify and rectify without referring to a separate file | Critical | - | done |
| 4 | Ignore empty msgStrings | MTRL4 | The system will ignore those entries in the po file that do not have a translated msgString value - for the purposes of this story a messageStr will be deemed to be empty of the line is equivalent to msgStr "". | High | - | done |
| 5 | File validation | MTRL5 | The system will check at the time of running that the two files specified by the user are for the same table and column element. This validation information will be taken from the header content of the PO file in line with the schema used in the Openbravo2PO transform process. | Medium | - | done |
| 6 | Folder input | MTRL5 | The system will have the ability to take in two folder locations and parse through the folders checking for duplicate files. On finding these duplicate files they will be merged into a single file and output in a designated output folder. The remaining files that are not duplicated will be directly copied to the output folder. | Low | 1, 5 | - |
Refactoring/Rework Phase
| ref | title | func spec ref | description | priority | dependencies | status |
|---|---|---|---|---|---|---|
| 1 | Clean MsgId str | REF1 | Only show both MsgId strings if they differ | Critical | - | done |
| 2 | Clean Matching duplicates | REF2 | If the MsgStr field for duplicated records match then this should be treated as a single entry and not marked as a duplication | Critical | - | done |
| 3 | MsgId and MsgStr match in XML file | REF3 | When the application transforms a file from XML to PO, if the Original and Value fields are the same the MsgStr should be empty. This is row in the PO file is represented as msgid "" | Critical | - | done |
| 4 | Feedback to User | REF 4 | The application will feedback to the user when errors are encountered during the execution process. This feedback should be to a log file. | High | - | - |
| 5 | Documentation | REF5 | Each process in the application should be documented in the Wiki. This will explain to the user how the application is used from a users perspective. | Medium | - | - |
Functional requirements based on business processes
MTRL1. Merge Two Files
USER STORY: The system will allow the user to define two .po files which will be merged in to a single .po file.
DETAIL: When the application is called from the command line or ant build script the user will be able to define two files which they wish to merge. The application will resolve these file paths and obtain the contents of the two files.
MTRL2. Create Unique Rows
USER STORY: The system will ensure that all unique translations between the files are created in the merge file in correct format that will allow the user to import them to the Openbravo2PO tool.
DETAIL: The process of merging the two files consists of firstly obtaining the uniques message elements from each file and creating them within the merged output file. Each output item will have a standard format which will be populated from the content of the original file content.
MTRL3. Highlight Conflicting Translations
USER STORY: The system create a single entry in the merge file for translations that are present in both import files. These conflicts will be easily searchable for the user to identify and rectify without referring to a separate file
DETAIL: In order that all information is collated from the two input files it is necessary to include those elements that are present in both files. The elements need to be cleaned by the user following creation of the merge output file and therefore all conflicts need to be clearly identifiable in a quick and simple manner.
All conflicting elements will include the string 'CONFLICT MERGED' in the first line of the message comments and the content of the MsgStr row will include both values enclosed in << >> identifiers. e.g. <<translation string 1>><<Translation String 2>>
MTRL4. Ignore Empty MsgStrings
USER STORY: The system will ignore those entries in the po file that do not have a translated msgString value - for the purposes of this story a messageStr will be deemed to be empty of the line is equivalent to msgStr "".
MTRL5. File Validation
USER STORY: The system will check at the time of running that the two files specified by the user are for the same table and column element. This validation information will be taken from the header content of the PO file in line with the schema used in the Openbravo2PO transform process.
MTRL6. Folder Input
USER STORY: The system will have the ability to take in two folder locations and parse through the folders checking for duplicate files. On finding these duplicate files they will be merged into a single file and output in a designated output folder. The remaining files that are not duplicated will be directly copied to the output folder.
User Interface Mockups
For this project there will be no user interface. All interaction with the merge tool will be through the command line and an ant build.xml task.