search

GALAglobal / TAPICC

The Translation API Cases and Classes (TAPICC) initiative is a collaborative, community-driven, open-source project to advance API standards in the localization industry.
https://galaglobal.github.io/TAPICC/
Other
24 stars 3 forks source link

Configure an automated build into HTML #3

Closed terales closed 4 years ago

terales commented 6 years ago

It's rather complicated to check out the current version of DocBook.

I suggest to set up an automatic build into GitHub pages. So non-devs could quickly read the latest version.

What do you think about it? If it's ok with you, I can prepare a PR, but it would require some guided configuration done by one of the repo collaborators.

DavidFatDavidF commented 6 years ago

Hi @terales, this is in fact in making. The only current DocBook draft is being published to our github.io pages in HTML and PDF preview versions. Our webpage content is in the docs folder. We didn't publicize that widely as it is yet very rudimentary.. So far we are using only preliminary, built-in oXygen transforms but Jano is working on modified stylesheets for HTML and PDF that will be tweaked and branded to our needs. We will publish those stylesheets along with the template once ready.. If you want to use those to automate the build, you're most welcome.. However not sure if we can fully automate the build on GitHub side, because a Saxon licence would be needed to run that..

terales commented 6 years ago

Oh, I see https://galaglobal.github.io/TAPICC/ Maybe it worse to add a link to README? Do you need a PR for this?

However not sure if we can fully automate the build on GitHub side because a Saxon license would be needed to run that

I'm basically thinking about integration with Travis CI: on each commit into the master branch, it would build it and, if build succeeds, commit it into gh-pages branch. GitHub would automatically redeploy assets from there.

It's okay to have any licensed tools because their keys could be stored in the secure environment variables at Travis CI.

I would be able to set up working configuration as an example, but eventually, you would have to create the same configuration from my instructions to keep project closed.

DavidFatDavidF commented 6 years ago

Alexander, I hear from Jano that ur active in WG4, meaning uv the legal signed.. I will ask Laura to give you write access, so that you can make the Travis integration. In fact we added Travis a while ago but no one had time to play with it ;-) Your help here would be most welcome.. I would wait with publicizing the github.io webpage for a bit.. But you can start playing with the automated Travis build right away.. Cheers and thanks dF

laurabrandon commented 6 years ago

Hi All -- I just sent an invitation to @terales for write access.

Thanks, Laura

JanHusarcik commented 6 years ago

Hi @terales

if that's OK with you, I'll assign this item to you. Re the output:

Jan

terales commented 6 years ago

Sure, thanks!

terales commented 6 years ago

Blocked by #5

DavidFatDavidF commented 6 years ago

@terales where did you get your xslt used for the build? The error message seemed to be that the xslt wasn't one.. I can commit the current oXygen transforms I am using to build and that store the outputs into my local doc folder..

terales commented 6 years ago

where did you get your xslt used for the build?

I believe that all required files, except binaries and files, included from third-party dependencies, should be in the repository.

With this idea in mind I was trying to use /docbook/T1/WG3/XLIFF-EM-BP.xml_xslt file as in the example command from suggested DocBook README:

java -jar saxon9pe.jar -xsl:./docbook/T1/WG3/XLIFF-EM-BP.xml_xslt -s:./docbook/T1/WG3/ -o:./docs/

I'm surprised a bit that you've merged draft of the README without addressing questions from PR #6. Sorry for not being clear. Let me explain what I was expecting based on my experience on open source software projects.

My initial idea was like this:

  1. I create a draft of DocBook building instructions (WIP prefix at PR mean work in progress, do not merge).
  2. Someone who can build the DocBook comes and either answer my questions in comments so I would update instruction or commit fixed instruction by himself.
  3. I would follow the instruction and verify that it could be reproduced from the clean machine by a person who just follows the instruction.
  4. If there are any troubles I'll ask for clarifications or missing files there.
  5. I remove the WIP suffix and ask to verify the instruction inside this PR.
  6. After positive feedback, I or someone else will merge it into the master branch.

Now I see that your approach is different. Can you share your plan, please?

DavidFatDavidF commented 6 years ago

You are right, I shouldn't have merged #6 It seemed to me on cursory reading that the #6 6 was already resolved.. Is there a way to reopen #5 and #6?

terales commented 6 years ago

Let me revert the merge and open a new PR

terales commented 6 years ago

Done: https://github.com/GALAglobal/TAPICC/pull/7

terales commented 4 years ago

I wasn't able to replicate settings from paid publishing software within scripting open-source environment.