Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs_devel: update contribution manual about document build and others #908

Merged

Conversation

miurahr
Copy link
Member

@miurahr miurahr commented Jan 14, 2024

Pull request type

  • Documentation -> [documentation]

Which ticket is resolved?

What does this PR change?

  • Fix URL typo
  • Add section about manual build tasks and explanation of container
  • Update about documentation project rules and procedures

Other information

Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Remove duplication with the contribution guide, and replace with links to the guide

Signed-off-by: Hiroshi Miura <miurahr@linux.com>
@miurahr
Copy link
Member Author

miurahr commented Jan 16, 2024

There are almost a technology side of document build, not about contribution rules and procedures.

A missing part is a build property option to skip html manual build when building and testing features.

@Kazephil
Copy link
Contributor

@miurahr
like the idea of splitting the developer documentation into a contribution guide and a build manual.

There's a lot of material in the developer documentation, so I'm going to wait until I can set aside a good chunk of time to do a proper review, which probably means sometime early in April, when work gets quieter.

Until then, I think we can still push the updates as is (maybe with a DRAFT label) to make information available. (It'll also be easier to review if it's up on the readthedoc.io site you set up.)

@brandelune What do you think?

Signed-off-by: Hiroshi Miura <miurahr@linux.com>
@miurahr miurahr changed the title docs_devel: update document contribution manual docs_devel: update contribution manual about document build and others Jan 18, 2024
@miurahr
Copy link
Member Author

miurahr commented Jan 18, 2024

There is very small section about a document contribution rule and procedure

https://github.com/omegat-org/omegat/blob/d875fb7795f7c1233d63d4afd3f18a3a55912718/docs_devel/docs/40.ContributingDocument.md

Comment on lines 9 to 10
Please contact to [Documentation manager](https://omegat.org/about) at [omegat-development mailing list]
(https://sourceforge.net/projects/omegat/lists/omegat-development) for details.
Copy link
Member Author

@miurahr miurahr Jan 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a space character between link text and url

Suggested change
Please contact to [Documentation manager](https://omegat.org/about) at [omegat-development mailing list]
(https://sourceforge.net/projects/omegat/lists/omegat-development) for details.
Please contact to [Documentation manager](https://omegat.org/about) at [omegat-development mailing list](https://sourceforge.net/projects/omegat/lists/omegat-development) for details.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would people need to contact the documentation manager ? People can do as they do for the code. Send PRs after creating issues on SF, on the documentation tracker.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I cannot find any document to describe rules and procedure in omegat.org website, and also in source tree. Please give a description. Otherwise, I can revert it to previous sentence; "[TBD]".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be valuable to add from https://omegat.org/support

documentation issues are handled on SourceForge by the Documentation tracking system. Please do not use these tracking systems before first raising the issue on the user group and/or mailing lists.

Jean-Christophe Helary added 8 commits January 19, 2024 10:42
A few rewording suggestions.
Various changes.

I put comments preceded by "->".
Few more fixes.
I removed most of the promotion for Docker and restructured the document a bit.

I think most of the last part is irrelevant now that we use containers.

I've added comments prefixed with "->".
Added reference to contribution rules, etc.
Add the link to Kos' explanations.
Small modifications
Various small fixes and a comment (check "->")
@brandelune
Copy link

@miurahr @Kazephil I have amended all the documents directly on the branch. There are a few comments (check lines that start with "->").

Thank you very much Hiroshi for this tremendously important work.

# Fonts

-> Aren't the fonts installed in the container?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They should be. This would apply to building the documentation without using a container, which requires the user to manually install all font and software dependencies.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, and if we still have the possibility to make manual build, I don't understand why we have a container requirement.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should probably be called a container option.

In theory, a container makes building the documentation easier than the manual process because it… well… contains everything!

Something strange seems to be going on with the manual build process, though. I'm getting everything inside a literal ${target} directory in doc_src\en\ instead of in the correct docs\en\ folder if I try to build with Ant. More investigation required.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something strange seems to be going on with the manual build process, though. I'm getting everything inside a literal ${target} directory in doc_src\en\ instead of in the correct docs\en\ folder if I try to build with Ant. More investigation required.

OK. It looks like building the documentation manually now requires passing both the -Dtarget and the -Dlanguage arguments to Ant.

I'm not sure why it didn't need to be passed explicitly before but is necessary now.

I think it might be a good idea to split this file into separate "using a container to build the documentation" and "building the documentation manually" files.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be a good idea to split this file into separate "using a container to build the documentation" and "building the documentation manually" files.

I agree. Thank you.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will work it.


### License

All the files in `doc_src` folder and below are under the terms of the GNU General
All the files in `doc_src` folder and below are published under the terms of the GNU General
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brandelune
I'm not a licence expert, but do software licenses apply to documentation?
Should this be one of the Creative Commons licenses?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The GPL is not specifically a software licence. It is a source code distribution licence. Our docbook sources are not supposed to have issues that can only be solved by using documentation specific licences. But if you find such issues, we need to investigate how to fix them, because changing the licence would be a major pain.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If XML is considered code, then there's probably no problem because the docbook sources can be defined as "source code".

I'll trust that whoever first chose the licence checked this at the time! :)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally, the manual was in HTML. There was no build process involved. The whole set was distributed under the GPL, and it just stayed like that. The Emacs manuals use the GFDL 1.3+ which makes sense, if I remember well, because they can also be distributed as books (cf. invariant clauses, etc.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting.

I found this interesting thread that's relevant.

If I understand it correctly, GPL for the docbook sources is fine. The actual manual(s) produced from those sources should probably be under the GFDL or one of the Creative Commons licences.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understood the thread (and GNU GPL FAQ) correctly, licensing the actual manual (output HTML, PDF, etc.) under the GPL would require including the contents of doc_src with the manual itself, which I think would be (a) cumbersome for us, and (b) tedious for users.

Of course, I might simply be misunderstanding the answers in the thread and FAQ.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FSF recommend GFDL for document rather than GPL in several reason.
https://www.gnu.org/licenses/license-recommendations.html

It is something extra-ordinal to apply GPL to a large manual document like OmegaT manual, so I try to add explanation here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that our choice of licence may not be the best, but we currently do not have issues that need to be solved by a change of licence.

It could be a fun exercise to track down the various authors that share the copyright on the current document though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the statement in the developer documentation here only applies to the docbook sources, so as far as those go, I think the developer documentation is fine as is in terms of contents.

The broader licensing issue may (or may not) be something to look at further down the road in the larger context of the entire project.
Have we explicitly applied the GPL (or any other licence) to the products output from those sources?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The GPL applies to the deliverables (the "program") and forces the developers to provide sources on demand so that users can modify the deliverable. The GPL is not a source file distribution licence.

Wording change, because documentation isn't really "developed". :)
@brandelune
Copy link

brandelune commented Jan 20, 2024 via email

Rewording of section on building Linux native packages using `jpackage`
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
@miurahr
Copy link
Member Author

miurahr commented Feb 10, 2024

Now all the reviewer feedback to be fixed are resolved.

@miurahr miurahr merged commit 64be720 into master Feb 10, 2024
9 checks passed
@miurahr miurahr deleted the topic/miurahr/docs_devel/documentation/how-to-build-manuals branch February 10, 2024 04:39
chelobaka pushed a commit to chelobaka/omegat that referenced this pull request Feb 10, 2024
omegat-org#908)

* docs_devel: update document contribution manual

Signed-off-by: Hiroshi Miura <miurahr@linux.com>

* docs_devel: Fix link URLs

Signed-off-by: Hiroshi Miura <miurahr@linux.com>

* docs_devel: Split manual contribution guide and build manual

Signed-off-by: Hiroshi Miura <miurahr@linux.com>

* docs: update doc_src/Readme.md

Remove duplication with the contribution guide, and replace with links to the guide

Signed-off-by: Hiroshi Miura <miurahr@linux.com>

* docs_devel: explain about build task and how to skip manual generation

Signed-off-by: Hiroshi Miura <miurahr@linux.com>

* Update Readme.md

A few rewording suggestions.

* Update 02.HowToBuild.md

Various changes.

I put comments preceded by "->".

* Update 02.HowToBuild.md

Few more fixes.

* Update 07.ManualContainerTaskBuild.md

I removed most of the promotion for Docker and restructured the document a bit.

I think most of the last part is irrelevant now that we use containers.

I've added comments prefixed with "->".

* Update 40.ContributingDocument.md

Added reference to contribution rules, etc.

* Update 45.LocalizeApplicationAndManuals.md

Add the link to Kos' explanations.

* Update 92.CodeSigning.md

Small modifications

* Update 93.BuildingInstallerPackage.md

Various small fixes and a comment (check "->")

* chore: Update 02.HowToBuild.md

* chore: Update 02.HowToBuild.md

Fix typo and slight rewording.

* chore: Update 40.ContributingDocument.md

Wording change, because documentation isn't really "developed". :)

* chore: Update 45.LocalizeApplicationAndManuals.md

Wording tweaks.

* chore: Update 92.CodeSigning.md

* chore: Update 93.BuildingInstallerPackage.md

Various wording tweaks.

* chore: Update 93.BuildingInstallerPackage.md

Rewording of section on building Linux native packages using `jpackage`

* chore: Apply suggestions from code review

Co-authored-by: Hiroshi Miura <miurahr@linux.com>

* chore: Delete resolved inline comment in 93.BuildingInstallerPackage.md

* docs_devel: split document build manual

Signed-off-by: Hiroshi Miura <miurahr@linux.com>

---------

Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Co-authored-by: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
Co-authored-by: kazephil <kazephil@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants