Re: [translate-pootle] Java properties with UNICODE encoding
On 26 October 2012 12:02, David Pérez Villanueva wrote: > Hola Julen, > > Thank you very much for your quick response... > > > If you're just playing, you may want to test the upcoming version from > > git which includes lots of changes comparing to 2.1.x. Although right > > now it's in a bugfix and polishing phase, it's pretty stable and it's > > even being used in some production environments. > > I'm playing but my goal is get an stable pootle for us. I'm trying to > convince my co-workers for using it and I need it will be working fine. > > > > The form options are auto-generated by querying the supported formats: > > > https://github.com/translate/pootle/blob/2.1/local_apps/pootle_store/filetypes.py#L60-69 > > > > As you point out there will be two identical identifiers used for > > different flavors of the same file type. If this was only a > > presentational issue, changing the identifier would solve it but... > > > > I don't know well enough how the format support is implemented, and it > > looks like this would have some other unwanted consequences, hence > > sounds like it's a bug. Friedel, Dwayne, could you confirm this? > I haven't tested but this does look like a bug. > I can't see too much on source code either, so I will try to create a > shell script to do all the process: > - Check native2ascii is required > - Copy files to destination > - commit to mercurial... > A quick solution might be to rip out the UTF-8 conflict from the code the Julen pointed to. Drawback, your maintaining a patch. The solution you suggest above would work well. You could do the same by using prop2po and po2prop instead of native2ascii. One last thought. I've never figured out why Latin1 is used for properties files, makes them unreadable without a machine. So you could maybe consider using native2ascii as a build time requirement and store the .properties in UTF-8 in Mercurial. Hope the above help. -- Dwayne *Translate* +27 12 460 1095 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
Re: [translate-pootle] Java properties with UNICODE encoding
Hi Dwayne, > A quick solution might be to rip out the UTF-8 conflict from the code > the Julen pointed to. Drawback, your maintaining a patch. I don't know python but it looks very similar to java so I'll try to have a glance to the code. > > The solution you suggest above would work well. You could do the same > by using prop2po and po2prop instead of native2ascii. I tried this but it didn't work for me. After this tests I saw we had some repeated properties so, this could be the real problem. Any way this doesn't avoid manage conversions and I've configured a easy way for updating from and to pootle with mercurial. > > One last thought. I've never figured out why Latin1 is used for > properties files, makes them unreadable without a machine. So you > could maybe consider using native2ascii as a build time requirement > and store the .properties in UTF-8 in Mercurial. I didn't understand why Latin1 is used also, but it is (http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.InputStream%29) The "real" source properties are managed with NetBeans and it write them in ASCII. If I let them in UTF-8, we will get a mixture between UTF-8 an ASCII properties... not a good solution for us. Thanks, David -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
Re: [translate-pootle] Java properties with UNICODE encoding
Hola Julen, Thank you very much for your quick response... > If you're just playing, you may want to test the upcoming version from > git which includes lots of changes comparing to 2.1.x. Although right > now it's in a bugfix and polishing phase, it's pretty stable and it's > even being used in some production environments. I'm playing but my goal is get an stable pootle for us. I'm trying to convince my co-workers for using it and I need it will be working fine. > The form options are auto-generated by querying the supported formats: > https://github.com/translate/pootle/blob/2.1/local_apps/pootle_store/filetypes.py#L60-69 > > As you point out there will be two identical identifiers used for > different flavors of the same file type. If this was only a > presentational issue, changing the identifier would solve it but... > > I don't know well enough how the format support is implemented, and it > looks like this would have some other unwanted consequences, hence > sounds like it's a bug. Friedel, Dwayne, could you confirm this? I can't see too much on source code either, so I will try to create a shell script to do all the process: - Check native2ascii is required - Copy files to destination - commit to mercurial... Thanks, David Pérez -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
Re: [translate-pootle] Java properties with UNICODE encoding
Hola David, og., 2012.eko urrren 25a 22:09(e)an, David Pérez Villanueva(e)k idatzi zuen: > > Hi. > > Iam trying to get pootle 2.1.6 working for internal use with our > languages files. I have one project working and Ihad translated some > literals for testing.Al is more or less working and I get my properties > updated on /po/project/XXX.properties. If you're just playing, you may want to test the upcoming version from git which includes lots of changes comparing to 2.1.x. Although right now it's in a bugfix and polishing phase, it's pretty stable and it's even being used in some production environments. > But I saw these properties are with uft-8 encodingwhen properties should > be on ISO-8859-1. > > I checked what was happening and I saw that when I'm creating a new > project, the file types available for java properties have the same value: > > > ... > *Java «properties»** > **Java Properties (UTF-8)* > ... > > > Does anybody knows if Is this a presentation layer error? If true,which > value must be stored to get "normal" java properties? If I know this > value, I can force it with firebug or something like that... The form options are auto-generated by querying the supported formats: https://github.com/translate/pootle/blob/2.1/local_apps/pootle_store/filetypes.py#L60-69 As you point out there will be two identical identifiers used for different flavors of the same file type. If this was only a presentational issue, changing the identifier would solve it but... I don't know well enough how the format support is implemented, and it looks like this would have some other unwanted consequences, hence sounds like it's a bug. Friedel, Dwayne, could you confirm this? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
[translate-pootle] Java properties with UNICODE encoding
Hi. Iam trying to get pootle 2.1.6 working for internal use with our languages files. I have one project working and Ihad translated some literals for testing.Al is more or less working and I get my properties updated on /po/project/XXX.properties. But I saw these properties are with uft-8 encodingwhen properties should be on ISO-8859-1. I checked what was happening and I saw that when I'm creating a new project, the file types available for java properties have the same value: ... *Java «properties»** **Java Properties (UTF-8)* ... Does anybody knows if Is this a presentation layer error? If true,which value must be stored to get "normal" java properties? If I know this value, I can force it with firebug or something like that... Thanks, David -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
