Bug 1072685 - RFE: Support source content other than en-US
Summary: RFE: Support source content other than en-US
Keywords:
Status: ASSIGNED
Alias: None
Product: PressGang CCMS
Classification: Community
Component: ImportTool
Version: 1.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Chris Bredesen
QA Contact:
URL:
Whiteboard:
Depends On: 1083348 1067783
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-05 02:59 UTC by Lee Newson
Modified: 2014-08-04 22:29 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)
xml_lang test (18.28 KB, application/zip)
2014-03-17 03:33 UTC, Matthew Casperson
no flags Details

Description Lee Newson 2014-03-05 02:59:41 UTC
Currently if you import content that isn't en-US, then it is imported incorrectly into PressGang.

As such the import tool should attempt to get the locale from the publican.cfg "xml_lang" parameter and if it can't get it from there (ie Mojo, DocBook imports) then it should ask the user. Then when the topic/content spec is created it should have the appropriate locale set.

Comment 1 Matthew Casperson 2014-03-17 03:33:26 UTC
Created attachment 875313 [details]
xml_lang test

Comment 2 Matthew Casperson 2014-03-17 03:34:51 UTC
Fixed in 201403171332

The import tool will default to en-US. This can be overridden with the xml_lang value in the publican.cfg file, and can be manually specified with a Mojo/ODT/generic docbook import.

Comment 3 Lee Newson 2014-04-02 03:13:30 UTC
I was able to import a publican book from a locale that wasn't supported by PressGang (this should probably be complemented with a server side check thinking about it atm).

Additionally publican books are going to use locales such as:

es-ES
ja-JP
de-DE

however in PressGang we match it to the Zanata locales (we may want to rethink that), as such these should be mapped from the relevant publican locale to the zanata locale.

The mapping as I know atm is:

PressGang -> Publican

ja -> ja-JP
es -> es-ES
de -> de-DE
fr -> fr-FR
pt-BR -> pt-BR (unchanged)
zh-Hans -> zh-CN
it -> it-IT
ko -> ko-KR
ru -> ru-RU
zh-TW -> zh-TW (unchanged)

So perhaps what we could do is remove the territory part from the passed locale (ie remove -US from en-US) and check if that matches a supported locale. If it does then ask the user if they want to use that locale. In the case of an unsupported locale I guess the system should just fail the import process.


Note You need to log in before you can comment on or make changes to this bug.