The Wayback Machine - https://web.archive.org/web/20210210085801/https://github.com/github/gitignore/pull/3086
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

Don't ignore *.pot files. #3086

Open
wants to merge 1 commit into
base: master
from

Conversation

@idgserpro
Copy link

@idgserpro idgserpro commented Jun 14, 2019

Reasons for making this change:

Although dynamically generated from i18n tools, in some situations (specially in the Plone world) you need to add a manual.pot with manual entries that need to be versioned.

Links to documentation supporting these rule changes:

https://github.com/plone/documentation/blob/0ea1b1f715e9031a434d72f57c189f25aa1f4b73/develop/plone/i18n/internationalisation.rst#manual-po-entries

Although dynamically generated from i18n tools, in some situations (specially in the Plone world) you need to add a manual.pot with manual entries that need to be versioned.

More information:

https://github.com/plone/documentation/blob/0ea1b1f715e9031a434d72f57c189f25aa1f4b73/develop/plone/i18n/internationalisation.rst#manual-po-entries
@idgserpro
Copy link
Author

@idgserpro idgserpro commented Dec 2, 2020

@shiftkey can you take a look here please?

@@ -52,7 +52,6 @@ coverage.xml

# Translations
*.mo
*.pot

This comment has been minimized.

@shiftkey

shiftkey Dec 3, 2020
Member

This rule has been largely unchanged for 7+ years, so I have several concerns about dropping this:

  • Most .pot files are generated, right? Would this be noisy to now have all .pot files in version control?
  • For situations where include/exclude files from version control is situational, we like to have a comment with context about when and why you should care about this rule. Here's an example:

# Only include if you have production secrets in this file, which is no longer a Rails default
# config/secrets.yml

Can we do that for this case, to explain for Plone usage what they should be aware of?

  • if we're trying to exclude a specific file by convention, could we keep this rule but add a !manual.pot or !lib/manual.pot rule to opt-in for this specific file?
@shiftkey
Copy link
Member

@shiftkey shiftkey commented Dec 3, 2020

@idgserpro the other concern I have about this change is interest from the community - I'm not familiar with Plone so I'm not sure how many people out there agree with this change.

@idgserpro
Copy link
Author

@idgserpro idgserpro commented Dec 3, 2020

Your concerns are valid. Actually, I don't know the motivation to version control *.pot files, but this has been for ages in Plone world.

@mauritsvanrees would you have more information about this?

@mauritsvanrees
Copy link

@mauritsvanrees mauritsvanrees commented Dec 29, 2020

I am one of the Plone Release managers. I am indeed used to having the .pot files in version control. I encountered a Plone project at a customer recently where the .pot file was ignored, and it surprised me, wondering why I did see changes in the .po files, but not in the .pot file.

Some reasons for versioning the .pot files:

  • Yes, you can regenerate the .pot file, but if someone uses a different tool for this, or a different version, I would like to see this difference in version control.
  • I find it useful to be able to update only the central .pot file to check what influence my code changes have there.
  • It makes it easy to copy the .pot file to a .po file for adding a new language.
  • I am simply used to it.

Something like !*manual.pot may work.
I am not using this gitignore project though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants