In Glotpress, I see 40 untranslated strings for WP 3.4 nn_NO, but the list of untranslated nn_NO strings is empty. Any ideas?
Updates from frilyd Toggle Comment Threads | Keyboard Shortcuts
-
frilyd
-
frilyd
Browsehappy nn_NO is ready. Pretty please with chocolate and cream on top and a big cup of hot, strong coffee to go with it, deploy?
-
frilyd
OK. So I have completed the 3.4 translation for nn_NO, re-populated 3.3 and all subprojects with the strings from 3.4 in Glotpress… Now what? I have to do something in svn to make a 3.3 tag, so I can build 3.3 from Rosetta? I fear to go into those mines.
-
Zé
I can do that for you, if you want… at least the svn part, which is simple. You just need to copy (not move) the contents of the “trunk” folder to the “tags/3.3” folder (and commit).
-
frilyd
I’ll try to do it myself, and eventually come back screaming for help if I happen to meet upon a balrog.
-
frilyd
My trunk/dist folder in svn is empty, so there is nothing sensible there to put in tags/3.3. Is there any reason why I shouldn’t use the content of /tags/3.0 to populate trunk/dist and eventually tags/3.3/dist? Are there changes to the sample files which I haven’t noticed?
-
frilyd
In general, I’m a bit confused as to which files go in svn and which don’t. It seems http://codex.wordpress.org/Translating_WordPress#Repository_File_Structure is a bit outdated, and nothing here at wppolyglogs tells me.
-
frilyd
Please? This is the only thing that’s stopping me from releasing. It would be nice to have it sorted.
-
Kenan Dervišević
dist folder in your 3.3 tag in the svn repository should have wp-config-samle.php and readme.html.
wp-admin folder has only one file called setup-config.php.
You need to translate these files in some text editor (PSPad or Notepad++) and upload them after that. When building your package, select the translate.wordpress.org as your source and tags/3.3 for “Local branch” and “WordPress branch” and everything should be fine.-
frilyd
Thanks a lot! Most helpful – now I’ve finally sorted out everything, and at last published 3.3 in nn_NO 🙂
-
-
-
-
-
frilyd
Hm. Is translate.wordpress.org down? I see no translations.
-
Zé
It’s working for me…which project and language are you looking at?
-
frilyd
Forget it, sorry for nagging 🙂 Didn’t work yesterday, but works now. A temporary hiccup.
-
Peter Holme
I actually got the same problem just now.. translations appear empty for multisite, twentyten, twentyeleven and continents-and-citites, and when I built the beta2 package, the po/mo-files are empty…
-
Kenan Dervišević
Now I’m having this problem. GlotPress is showing 321 strings for 3.3 (http://bit.ly/owkx9F) and no strings for Multisite, Twenty Ten and Twenty Eleven.
-
Rami
same for me. and not only for wordpress, but other projects also.
-
Mattias Tengblad
Any one checking this out? Something is definitely wrong with translate.wordpress.org. Some times there are no strings, other times there are ~300 strings (at this moment this is whats showing http://twitpic.com/740q4z ). It hasn’t been the correct number of string at any time the latest week when I’ve checked.
Had to fall back on beta 1 strings when releasing beta 2.
-
Mattias Tengblad
?????
-
-
-
frilyd, 
Wacław J., and 
frilyd
As mentioned many times before, validators often unintentionally release beta versions (aortic dissection etc). I’m far from the only one with this problem: Many of us are simply translators with too little time. What I’d like, is something very simple, like “release the latest stable WordPress in nn_NO from Glotpress”. It would be a great relief not to have to worry about file revision numbers ever again. Please, can it be?
-
Andrew Nacin
I’ll take a look.
frilyd
WP 3.2: Do the translators need to do changes in svn to make beta versions of 3.2 become available in their language?
-
Zé
http://core.svn.wordpress.org/trunk/wp-includes/version.php indicates (as of right now) ‘3.2-beta1-17999’, so that building from trunk (core and yours) should produce a 3.2 Beta 1.
-
frilyd
Thanks!
-
Zé
Please let us know how that went. It seems there may be some issues with building from rosetta.
-
frilyd
Same error as described below. The .po file is translated according to translate.wordpress.org and contains 3278 strings, while the .mo file only contains only 828 strings.
-
Kenan
I’m having the same issue on bs_BA. .mo files are always pulled from the svn (if they exist there). I reported this last week, but it hasn’t been resolved (link).
-
Zé
Confirmed. Working on a fix, workaround for the moment is to remove the .mo from svn before building from GP.
-
frilyd
I have now svn deleted the erroneous .mo file from the i18n svn server. I feel very adventurous and brave.
-
Zé
Live dangerously 🙂
-
-
-
-
-
-
-
frilyd
Referring to this post: today I tried building nn_NO from Rosetta without using revision numbers (project 3.1 and 3.1.x). I get an error message (“invalid revision”). That probably means that I have to look up revision numbers every time I want to build a new nn_NO release, which is a slight annoyance and a source of error. Why do I have to do it?
More seriously, the current nn_NO translations are broken, although all strings in translate.wordpress.org are translated. Scrutiny reveals that all strings the .po files in an update, and in a fresh download, are fully translated. The .mo files, on the other hand, contain only 828 translations. There is something wrong, and I can’t find out what. I’d be thankful if anyone would care to look at nn.wordpress.org. and examine the language files to confirm the problem, and find out how I get fully translated .mo files.
-
frilyd
Further investigation: Building from dist file branch “trunk” gives wrong .mo files, while building from branch “tags/3.0” gives correct (or at least better) .mo files. I eagerly await the codex file about releasing localised builds. I thought I knew this, but now I am in doubt about what really is the correct procedure for releasing localised builds.
frilyd
In the good old days (some months ago), we didn’t have to use revision numbers when releasing new localised WordPress versions. I’ll be blunt: Why do we have to use revision numbers? It’s a source of errors and some frustration. Can’t we go back to the way it was before?
-
Xavier
I’ve never had to do that. Revision numbers are for those who cannot wait for the building tool to feature the real version number, methinks.
-
Peter
So you always use “HEAD”, or what?
-
frilyd
I tried (around the release of 3.1, I think) to just use the automatic values. That gave me 3.2-bleeding, in en_US, which is not what I want. Later, I released using revision numbers, which has sort of worked until now. Lately, users have reported that they can’t update to the new nn_NO version from the dashboard. My last release was according to https://wppolyglots.wordpress.com/2011/04/26/you-can-use-revision-17712-to-compile-your/#comment-2218 .
I’ll try to release without revision numbers, and see what happens. If it ruins my test installation, I’ll delete that release.
-
Zé
Remember that you don’t need to release to test, you can download an unreleased build from the dashboard.
-
frilyd
That of course is an alternative. I can try that first, and then (if it works) release it and see if it also works via dashboard upgrading. Thanks. Will report back.
-
frilyd
Hi. Could you add me as nn_NO translator for the wordpress.com projects, including Jetpack? My wp.com username is frilyd. (I’m already maintaining the .org nn_NO translations, thinly guised behind the username meinmycell.) Thanks.
-
Zé
All set
WP Polyglots 
Andrew Nacin 3:54 pm on June 28th, 2012 Permalink |
Where does it say you have 40 untranslated strings? URL, screenshot?
Wacław J. 12:41 pm on June 29th, 2012 Permalink |
The same happens in pl_PL: https://translate.wordpress.org/projects/wp/3.4.x
It says there are 40 untranslated strings, while in fact there are none (a caching issue I guess? I think it was already discussed somewhere).
frilyd 7:44 am on July 4th, 2012 Permalink |
It probably was a caching issue, because everything is OK now. Thanks!