I am using Django translations for a project, and would like to ensure, on TravisCI, that translations are not left behind when changes are made to translatable strings.
This is a simplified snippet of my .travis.yml:
script:
- ...
- python manage.py makemessages -l ja --no-wrap --no-location
- git diff --exit-code
That recreates the PO files, and fails when the file changes. So far so good.
Unfortunately, django updates the POT-Creation-Date every time the script is run, and I can't see any flags to makemessages that would disable that, so even if there are no changes, the file changes on every run.
Am I on the right lines, or is there a better way to detect that there has been a change?
So, after makemessages diff will allways show at least 1 insert and 1 deletion, right?
git diff --numstat | awk '{if ($1>1 || $2>1) { exit 1 } else { exit 0 }}'
This script should exit with status=1 if there is more than 1 insert and 1 deletion in diff.
Git now has a nice way to ignore specific matches. The following line will fail if there is a diff, but exclude the problematic header:
git diff --ignore-matching-lines=POT-Creation-Date --exit-code
What's better, Django recently merged a change to stop this header from getting updated when there are no changes to the translations. It hasn't been released as of Django 4.0, so I expect it will arrive in Django 4.1.
See Django bug #6106 and the commit that fixes this issue.
Related
I use wget as part of script to fetch a URL eg. "www.myremoteurl.com/subpage/index-X.run", but X is a integer that keeps incrementing/changing breaking the script as the resource will not have existed.
ok, then, it's easy!, as you imaged
#!/bin/sh
for i in {1..10}
do
wget www.someurl/someindex-$i.run &
done
this would loop from 1 to 10 and ignore any failure, should be handy for some normal cases
I regularly use the following git-log command:
git log --oneline --graph --decorate --all
The command is perfect for me, with one exception. I maintain a set of refs in refs/arch/ that I want to keep around ("arch" stands for "archive"), but I do not want to see them every time I look at my git log. I don't mind them showing up if they are an ancestor of an existing branch or tag, but I really do not want to see series of commits that would not otherwise show up in the git log but for the fact that they are in the commit history of a given refs/arch/* ref.
For example, in the image below, the left-hand side is an illustration of what I see currently when I run git log --oneline --graph --decorate --all. As you can see, the commit referred to by refs/arch/2 would not show up in the log if that ref didn't exist. (Assume there are no refs that are not shown in the left-hand side image.) Now, the right-hand side is an illustration of two alternative log graphs, either of which would be perfectly fine. I don't mind seeing anything matching refs/arch/* so long as it is in the commit history of a branch or tag. But, in the image below, I definitely do not want to see the commit referred to by refs/arch/2.
How can my git-log command be modified to suppress refs/arch/* in either of the senses depicted in the illustration?
What you want is:
git log --oneline --graph --decorate --exclude 'refs/arch/*' --all
The --exclude option is new in git 1.9.0.
From the git-log manual page:
--exclude=<glob-pattern>
Do not include refs matching <glob-pattern> that the next --all, --branches, --tags, --remotes, or --glob would otherwise consider. Repetitions of this option accumulate exclusion patterns up to the next --all, --branches, --tags, --remotes, or --glob option (other options or arguments do not clear accumlated patterns).
The patterns given should not begin with refs/heads, refs/tags, or refs/remotes when applied to --branches, --tags, or --remotes, respectively, and they must begin with refs/ when applied to --glob or --all. If a trailing /* is intended, it must be given explicitly.
If you are on some flavor of Ubuntu you can upgrade git from the Ubuntu Git Maintainers team ppa.
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get upgrade
We are having problems in synchronizing our PO files with Pootle:
Lost translations
The first problem we encountered was that of lost translations. After doing an update_stores, some of our translations would be missing in Pootle. We have tried to remedy this with using the --keep option, but this had the adverse effect of not removing obsolete translations. We would like Pootle to hide obsolete translations, but not throw them away (the translation is obsolete, but still valid). Our current solution to this problem is to call sync_stores with the --overwrite option before calling make_messages
Wrong translations, not marked as fuzzy
When we add a new message id to the PO file, Pootle will sometimes translate the message (using a bad translations, probably found using fuzzy matching) without activating the fuzzy flag.
Our current work-flow for synchronizing Pootle and our PO files is:
(adding new messages to pootle)
1. call "pootle sync_stores --overwrite" to update local po files with pootle contents
2. call "python manage.py makemessages -a" to add new messages to the po files
3. call "pootle update_stores" to import the latest po files in pootle
4. call "pootle update_translation_projects" to refresh pootle views
(updating po files with pootle contents)
5. call "pootle sync_stores --overwrite" to update local po files with pootle contents
6. call "python manage.py compilemessages" to create the mo files
The above tricks have reduced the number of errors somewhat, but we are still experiencing the above mentioned problems. Have you found similar problems? Have you been able to solve them?
I am trying to add a few new columns to certain tables in Joomla, since i need to migrate these fixes from dev to production i am trying to do this the clean way, updates trough the filesystem.
I have followed a few tutorials concerning this and did the following.
I created the folder updates/sql and put a new sql file in it with my new version (1.5).
I changed the version number in my xml file.
I refreshed my cache in the backend.
Here are the codes I used:
My version:
<version>1.5</version>
The update node:
<update>
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
<schemapath type="sqlazure">sql/updates/sqlazure</schemapath>
</schemas>
</update>
The sql file:
ALTER TABLE `#__mycomponent` ADD `field` VARCHAR(255);
I tested my query directly against the database and it worked, what am I missing?
Short answer - Joomla!'s DB migration tool only does them after uploading a new component via the Component Manager. It doesn't check for a migration on every $_REQUEST, which is what your question suggests.
Longer Answer
Make sure you run the upgrade via the component manager. Simply over-writing the files doesn't trigger Joomla's migration process. Check the #__schemas table for your component's ID, and it'll have a corresponding database schema version #. If that version hasn't incremented yet, then the migration wasn't applied.
Part of the problem is
I am trying to do this the clean way, updates trough the filesystem
While I agree with you, that would be the clean way: Joomla! wants you to do things the Joomla! way ;-)
Important Note about Joomla! SQL Files
SQL files cannot contain C style comments (# comment here), and must contain comments like this -- comment here Spent a few hours debugging my own code, and had to re-run an upgrade about 25 times to figure out where the database schema migration was failing.
Comments may support the /* Comment */ style syntax, but I have yet to test that as extensively. YMMV.
Each time I added some strings to a Django project, I run "django-admin.py makemessages -all" to generate .PO files for all locales.
The problem is even I only added 5 news strings, the makemessages command will mark 50 strings as fuzzy in .PO files which brings a lot of extra work for our locale maintainers.
This also makes the entire i18n unusable before they manually revise those fuzzy strings.
Removing fuzzy is exactly what I am doing... check this out.
http://code.djangoproject.com/ticket/10852
Sounds like we need extra sh script that automatically removes all the fuzzy from po.
You can use the gettext command line tools to do this now:
msgattrib --clear-fuzzy --empty -o /path/to/output.po /path/to/input.po
The Django management commands just call these tools directly, so you must have this installed. The makemessages uses msgattrib to clear the obsolete strings by setting the output to the same as the input, so I suspect you can do the same with the above to remove fuzzy strings.
From the msgattrib man page:
--clear-fuzzy
set all messages non-'fuzzy'
--empty
when removing 'fuzzy', also set msgstr empty