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

Translation to German #25

Closed
GoogleCodeExporter opened this issue Aug 23, 2015 · 22 comments
Closed

Translation to German #25

GoogleCodeExporter opened this issue Aug 23, 2015 · 22 comments

Comments

@GoogleCodeExporter
Copy link

Hello, 

on the main page it says "Translators wanted". I'd be willing to offer a German 
translation for this project, as I quite like it and would love to have the 
output in German. 

In https://code.google.com/p/gitinspector/wiki/Contributing it says to just 
open a new issue for a translation, but sadly it does not tell about how to 
translate. I've already seen some existing translations, but can't figure out 
what the non-plaintext file is. 

I also tried finding previous translation issues, but was unable to find any.

So, if there is need for a German translation, please provide instructions on 
how to translate.

--


Original issue reported on code.google.com by [email protected] on 9 Feb 2014 at 2:17

@GoogleCodeExporter
Copy link
Author

Hi. Translations are always welcome.

The translation system uses standard GNU gettext for handling the translations. 
For more information about gettext; please refer to the following:

https://en.wikipedia.org/wiki/Gettext
https://www.gnu.org/software/gettext/

When writing the actual translation, it is often easier to use a .po editor 
instead of a plain text editor. They are very helpful when you (for example) 
extend an already exisiting translation:

https://wiki.gnome.org/Apps/Gtranslator
https://www.poedit.net/

The .mo file that is used by gettext to load the translation is generated using 
the command msgfmt (part of GNU gettext). For example:

msgfmt <po file> --output-file <mo file>

Also, poedit (link above) supports generating .mo files from within the editor 
itself.

When you start a new translation, it's just a matter of loading the .pot file 
(po template) directly into poedit or Gtranslator and get going.

When you test the translation you should save the translation files with the 
language code appended to the file name (de for german):

translations/messages_de.mo
translations/messages_de.po

/Adam Waldenberg

Original comment by [email protected] on 13 Feb 2014 at 9:34

  • Changed state: Accepted
  • Added labels: Milestone-Release0.4.0

@GoogleCodeExporter
Copy link
Author

I finally got around finishing the translation and have saved the patch as 
gist: https://gist.github.com/xxyy/3a595ea390031a6a4eac

There is a problem with plaintext output, I had to use HTML escape characters 
for HTML output (as the generated HTML does not seem to specify UTF-8 encoding) 
and these are displayed in plaintext/XML output, which looks kind of ugly.

Side note, I had to temporarily hard code German language files for testing, as 
the localisation system did not want to recognize my system language - I'd 
appreciate if it was possible to specify the display/output language via CLI 
argument (This would also be useful if you want to generate stats in a language 
different from your system language) [These changes are obviously not included 
in the patches]

Original comment by [email protected] on 20 Feb 2014 at 10:45

@GoogleCodeExporter
Copy link
Author

Great! Before we include it in the 0.4.0 release it's probably going to need a 
few additional string as well. I'll notify you in this issue when it nears a 
release.

UTF-8 is indeed specified in the generated HTML output with charset=utf-8. So 
it should work. What browser and operating system are you using? Using html 
escape sequences in the translation string will break the output for the other 
output formats such as txt and xml, so that isn't a solution. Maybe it is 
related to poedit. It seems to have some troubles with UTF-8. For example 
(https://www.poedit.net/trac/ticket/145). Maybe there is something wrong with 
the unicode characters inside the generated .mo.

If you remove the escape sequences I can generate the .mo file for you and 
attach it in this issue. 

It's possible to specify (force) a different system language by setting the env 
variable LANG, for example:

export LANG=de_DE.UTF-8 (linux/unix terminal)
set LANG=de_DE.UTF-8 (windows terminal)

for german :).

However, it would be interesting to know why the detection is failing on your 
system.

/Adam Waldenberg

Original comment by [email protected] on 21 Feb 2014 at 11:00

@GoogleCodeExporter
Copy link
Author

I tried forcing, but set it to just 'de'. That explains why it didn't work :)

The failing might be related to me trying to switch my (Windows 8.1 x64) System 
Language to English (I just like that more, don't ask why) and then switching 
back to German (Some applications that I paid for didn't really like the change)

Here's the .po without escape sequences (Poedit indeed seems to have some 
issues with UTF-8): https://xxyy.nowak-at.net/misc/messages_de.po

Original comment by [email protected] on 21 Feb 2014 at 9:15

@GoogleCodeExporter
Copy link
Author

I tested the translation and it works like a charm. Good work. I'm attaching 
the .mo file with this post.

I did find two things that need fixing: 

1. The --version information isn't translated (short license text).

2. The changes output looks like this when running with german  on the 
gitinspector repo:

//-

~/Projekt/gitinspector/gitinspector $ ./gitinspector.py -f po,pom,py -L
Statistical information for the repository 'gitinspector' was gathered on 
23.02.2014.
In der folgenden Tabelle sind Autoren und Änderungen zusammengefasst:

Autor                      CommitsEingefügte ZeilenGelöschte Spalten% der 
Änderungen
Adam Waldenberg                238          6885           3938           91.43
Bill Wang                        2           352             94            3.77
Chris Ring                       2            11              4            0.13
Kamila Chyla                     1           271              0            2.29
Luca Motta                       1           282              0            2.38

//--

The text output is designed to fit on a 80-character terminal; so you'll have 
to come up with something shorter, if possible.

Didn't find any other issues and the UTF-8 encoding seems to be correct.

/Adam Waldenberg

Original comment by [email protected] on 23 Feb 2014 at 5:34

Attachments:

@GoogleCodeExporter
Copy link
Author

I translated the version information, but sadly it does not show up. I checked 
the generated .po file, and the translation is there - just the same as in the 
code.

Also, from blame.py, the Strings "Age" and "Stability" are missing in the .pot 
file.

I fixed the width of text output though: 
https://screencloud.net//img/screenshots/9438fc5dfa4c6d3df33b15468479b7bd.png 
(the line at the right marks 80 characters)

The first line of text output also seems to be missing in the .pot file.

By the way, I set the environment variable in the way you described (and 
verified it was set to that), but the code still chose the English locale 
(lang=English_(United Kingdom)).

Umlauts in the HTML output are still not working [Still Windows 8.1, latest 
Chrome and Firefox Nightly], not even with your .mo - They are not even shown 
correctly in the source (of the HTML) or the .mo file (I tried replacing the 
strange stuff with the proper characters using Notepad++, but that lead to a 
parsing error ._.)

I attached the file in case you know anything else to do.

Original comment by [email protected] on 23 Feb 2014 at 9:07

Attachments:

@GoogleCodeExporter
Copy link
Author

Looking good! I'll take a look at the version string and get back to you.

Yes... There are a few new strings that have been added in the master branch... 
They will be added to the .pot shortly before the 0.4.0.

Concerning the international characters in the html output; that is very 
strange. I tried to generate a html page on the current master branch of 
gitinspector. It is behaving correctly when I run it. I'm attaching that file 
with this post; see how it looks for you. I'm also attaching a fixed .po where 
the version string should show up for you.

If the code still uses English that means there is no german locale on the 
system and the call to "locale.setlocale(locale.LC_ALL, "")" in the Python code 
is failing. Thats's my guess at least. Maybe this is what is causing the 
characters to show up incorrectly without escaping?

You could give the following Python program a try:

from __future__ import print_function
import locale
locale.setlocale(locale.LC_ALL, "")
lang = locale.getlocale()
print(lang)

Just to check where it is failing... Might give us a clue.

/Adam Waldenberg

Original comment by [email protected] on 24 Feb 2014 at 2:53

Attachments:

@GoogleCodeExporter
Copy link
Author

Without having checked the rest, the code you gave does the same as 
localisation.py, where I output the lang variable which was English_(United 
Kingdom), as noted above. (With %LANG% set to de_DE-UTF8)

(I am on mobile right now)

Original comment by [email protected] on 24 Feb 2014 at 12:23

@GoogleCodeExporter
Copy link
Author

What does it do if you call

lang = locale.getdefaultlocale()

instead? Same result?

/Adam Waldenberg

Original comment by [email protected] on 24 Feb 2014 at 1:28

@GoogleCodeExporter
Copy link
Author

Similar result, but makes no difference, since only the first two characters 
are taken by the implementation. https://screencloud.net/v/vqzL

Funny enough, the HTML file you provided works just fine.

If I generate a .mo on my system with the .po you provided and run 
gitinspector, it does not work. (Command line: python gitinspector.py --grading 
-F html -L >test.html) https://screencloud.net/v/odKh

As a result, I think the issue is something on my system - not sure what though.

Original comment by [email protected] on 25 Feb 2014 at 11:50

@GoogleCodeExporter
Copy link
Author

Well. For starters, Python is detecting your system language to be English. 
Still, forcing the language should still work. Then again, we are talking about 
Windows, so anything is possible ;).

I'm not quite sure what is happening... Are you runing under Python 2.* or 
Python 3.* ? If you are under Python 2, you could try changing the following 
function in "terminal.py":

108 | def set_stdout_encoding():
109 |         if not sys.stdout.isatty() and sys.version_info < (3,):
110 |                 sys.stdout = codecs.getwriter("utf-8")(sys.stdout)

to:

def set_stdout_encoding():
        pass

and see what happens. Maybe there is something affecting it there during 
redirection. Don't forget to do

set LANG=de_DE.UTF-8 (windows terminal)

before running gitinspector :).

Original comment by [email protected] on 26 Feb 2014 at 7:15

@GoogleCodeExporter
Copy link
Author

https://screencloud.net/v/51Jv <-- LANG seems to be working with the modified 
terminal.py, the umlauts are still not working though ._.
Result without the change: https://screencloud.net/v/rgaF (Same output)
The language thing now seems to work, the encoding is still messed up.

Original comment by [email protected] on 9 Mar 2014 at 11:41

@GoogleCodeExporter
Copy link
Author

Interesting. I will try to reproduce your environment in a local Windows 
installation and see if I can get it to behave in the same manner.

I'll get back to you with my findings when I'm done.

/Adam Waldenberg

Original comment by [email protected] on 10 Mar 2014 at 12:09

@GoogleCodeExporter
Copy link
Author

I have successfully reproduced the bug. It seems that something is happening 
under Windows when redirecting to stdout. International characters are 
scrambled and incorrectly outputted. This happens regardless of if you 
overwrite the current language or not. If there are international characters - 
it doesn't seem to want to work.

It seems to be fixed in Python 3 - it tends to behave better under Windows than 
2.* does. However, it is supposed to work in 2.6+ as well.

I will investigate this further and check if it can be fixed. However, I don't 
really see anything wrong with the code... But maybe there is a workaround. 
Maybe using the Windows API directly (instead of the Python one) could solve it.

/Adam Waldenberg

Original comment by [email protected] on 18 Mar 2014 at 9:46

@GoogleCodeExporter
Copy link
Author

Hi. It's time for an update to the translation.

Any translations that are not updated will not make it into the next release. 
My hope is to release version 0.4.0 of gitinspector some time during December.

Please refer to revision 4d6e51a760be in order to see what has changed since the
last version of the pot file.

/Adam Waldenberg

Original comment by [email protected] on 29 Nov 2014 at 6:16

  • Changed state: NeedsFeedback
  • Added labels: Priority-High
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

I have updated my translation using the current .pot file.

Plase find the changes at 
https://code.google.com/r/supertux22-gitinspector-de/source/detail?r=611f211c47b
ce9d9ab1ac4acd639757c7e7e75e6 . I tried to push to the main repository, but got 
an error (repository doesn't exist), so I made a clone.

Also, I'm using Arch linux for my primary OS now instead of Windows and the 
Umlauts seem to be working fine, with both html and text output formats  :) 

Original comment by [email protected] on 30 Nov 2014 at 2:45

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Sounds good! A clone is a good solution. I can just cherry pick whatever I need.

I never really figured out why it refuses to work under Windows + Python 2. In 
any case, there doesn't seem to be any "easy" or directly apparent solution to 
the problem.

/Adam Waldenberg

Original comment by [email protected] on 1 Dec 2014 at 8:20

@GoogleCodeExporter
Copy link
Author

This issue was updated by revision a42726aedbeb.

Original comment by [email protected] on 8 Dec 2014 at 10:08

  • Changed state: Done

@GoogleCodeExporter
Copy link
Author

Done. I also took the liberty of adding your full name to the translation and 
did some minor tweaks as per revision 8c464fddd41b.

/Adam Waldenberg

Original comment by [email protected] on 8 Dec 2014 at 10:22

@adam-waldenberg adam-waldenberg added this to the 0.4.0 milestone Aug 24, 2015
@adam-waldenberg adam-waldenberg modified the milestones: 0.4.2, 0.4.0 Oct 2, 2015
@adam-waldenberg
Copy link
Member

Hi. A new messages.pot has been added with commit 47b11ad, so an update is needed to the translation file. Refer to the commit diff to see all changes.

Once updated, the translation can be included in the upcoming 0.4.2 release.

@adam-waldenberg adam-waldenberg self-assigned this Oct 2, 2015
@literalplus
Copy link
Contributor

I will see if I can find time to update the translation for the release, don't count on it though.

@adam-waldenberg
Copy link
Member

Hi. No worries. Do it when you have time available. We can always make an extra 0.4.3 release for any translations that don't make it into 0.4.2.

@adam-waldenberg adam-waldenberg modified the milestones: 0.4.3, 0.4.2 Oct 14, 2015
literalplus added a commit to literalplus/gitinspector that referenced this issue Oct 20, 2015
This commit updates the German translation for
the 0.4.3 release. Changes in translation
include updating for changed messages in
upstream and some rewording. Also, this
commit includes a different translation
for "cyclomatic complexity" because the
previously used one (by inventor's name)
might be less clear than the current,
literal translation, which seems more
intuitive, especially in a world where
English is dominant in software dev,
so people are more likely to know only
the English word.

Some translations have been changed to
be more clear and to the point. Some
comments have been added to messages
that have been causing issues.
literalplus added a commit to literalplus/gitinspector that referenced this issue Oct 23, 2015
This commit updates the German translation. Changes in translation
include updating for changed messages in upstream and some rewording.
Also, this commit includes a different translation for "cyclomatic
complexity" because the previously used one (by inventor's name)
might be less clear than the current, literal translation, which seems
more intuitive, especially in a world where English is dominant in
software dev, so people are more likely to know only the English word.

Some translations have been changed to be more clear and to the point.
Some comments have been added to messages that have been causing issues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants