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

Readme and license links to not work on https://galaglobal.github.io/TAPICC/ #16

Closed simonech closed 6 years ago

simonech commented 6 years ago

The two links point to readme and license using ../ but the github pages root is the doc folder and those files are outside of the root.

JanHusarcik commented 6 years ago

Hi Simone. Thanks for reporting the issue. Would #20 work for you?

J

simonech commented 6 years ago

That is a possible solution, but linking from the website to the page in the github repo directly (so getting out of the site) is not the good solution IMHO. The problem is that you are kind of mixing source repository and "distribution" platform in the same repo. If the "doc" folder is where your github.io site resides, everything should be inside there. This way of structuring the repo is also what lead to the situation I reported in issue #15, where one folder is the source, and the other 2 are the publication of the source and the "versioning" of the different releases of the publication. I understand this is how you are used to do for versioning standards, with the "current/latest draft" version and all the other official previous releases, but github is not a publishing platform, but is a source versioning platform. This is long talk I already had with @DavidFatDavidF at the JIAMCATT conference in May. I'd keep in this repo/branch only the source, and via some build process (like the DocBook mentioned in the other issue) create releases for the github.io site, which should be in either a different repo or at least in a different branch. And then tag the source with each "official" release.

DavidFatDavidF commented 6 years ago

I agree with @simonech in principle, however, we don't have always the time and volunteers to do the right thing right. We need to launch the XLIFF Extraction and Merging Best Practice today and so accepting this solution for the time being is what we need to do. @simonech if you're going to design the process how to build and publish the review deliverables using a branch that would be great and we're willing to go there. I just think we need this quick, dirty, and efficient solution for now..

simonech commented 6 years ago

I’ve commented on the other issue some time ago but no reaction from the guy that was working on it. I’ll see if I can take over that task in the upcoming weeks

Sent from my iPhone

On 28 Jun 2018, at 14:36, dF notifications@github.com wrote:

I agree with @simonech in principle, however, we don't have always the time and volunteers to do the right thing right. We need to launch the XLIFF Extraction and Merging Best Practice today and so accepting this solution for the time being is what we need to do. @simonech if you're going to design the process how to build and publish the review deliverables using a branch that would be great and we're willing to go there. I just think we need this quick, dirty, and efficient solution for now..

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.