[Qgis-tr] [Qgis-developer] size of translations, use a distinct repo?
Werner Macho
werner.macho at gmail.com
Wed Nov 12 01:11:02 PST 2014
Hi!
Yeah - that's how I understood it too.
So no updates in the source tree anymore (do everything in transifex -
because that is what it is for) and only pull the translations and
commit them ONCE right in front of a release.
Everything else (pulling, updating) is done on the fly before (or
during) a compile run.
Sounds like a good plan to keep the translation updates having a
minimal impact to the source repository.
+1 from me
kind regards
Werner
On Wed, Nov 12, 2014 at 10:06 AM, Richard Duivenvoorde <richard at duif.net> wrote:
>
> Hi Werner,
>
> I think Jürgen is right, we do not need to PULL the qgis_en.ts from
> transifex anymore.
>
> The only function of that ts file is:
>
> -1- to use as a template (pot?) for all other language during updating
> of other ts files
> BUT we actually do not need to pull back this anymore, as for building
> (languages) we PULL the non-english ones from transifex. This (pulling)
> could indeed be a compile step if you want, though it needs you to have
> the tx-cli tools in place for this.
>
> -2- to be the 'source' for transifex.
> So we only need to PUSH the english version to transifex (when the
> source strings have been changed).
>
> Plz correct me if I'm wrong.
>
> regards,
>
> Richard
>
>
>
> On 12-11-14 09:41, Werner Macho wrote:
>> Hi Jürgen!
>>
>> I am not sure what are you aiming at, but yes - we could do it that way too.
>> As long as QGIS does not use qgis_en.ts we could just tx pull it -
>> update it and tx push it back to transifex.
>> (And forget about it in the source tree). The same way we could do it
>> with all the translations.. pulling the right in front of a compile
>> run and forget about them afterwards and only commit them right in
>> front of a branching the release branch.
>> As I said - as long as translations can be considered to be in the
>> nightly build I am confident that people compiling QGIS on their own
>> can also pull translations before they build.
>> The only problem I see is when nightly is not updating translations
>> and people cannot see their translations (and possibly adjust it).
>> (This only because I sometimes got asked about updating the languages
>> in the source tree so that translators can see the work before it is
>> getting "released")
>> If I am getting you correct we could update the i18n directory only
>> once per release. Is this what you are aiming for?
>>
>> kind regards
>> Werner
>>
>> On Wed, Nov 12, 2014 at 9:31 AM, Jürgen E. <jef at norbit.de> wrote:
>>> Hi Werner,
>>>
>>> On Tue, 11. Nov 2014 at 23:24:07 +0100, Werner Macho wrote:
>>>> Sounds like a reasonable idea to me, if the translations will be in
>>>> nightly I've got no problem (and I also think that the translators
>>>> don't have any). For people compiling out of sources it shouldn't be
>>>> any problem to pull from transifex either and compile.
>>>
>>> If I update qgis_en.ts the usual way, there are now differences (e.g. '
>>> instead of '). Looks like qgis_en.ts was pulled from transifex. Is that
>>> necessary for anything? And how does transifex handle changes like that?
>>>
>>> On second thought do we need a uptodate qgis_en.ts in our repository at all?
>>> QGIS doesn't use it - it's only there for transifex to watch.
>>>
>>> Instead of updating and commiting it in the source repository (and see lots of
>>> otherwise useless changes) we could simply have update_ts_files.sh pull it from
>>> transifex, update it with the latest source changes and push it back.
>>>
>>>
>>> Jürgen
>>>
>>> --
>>> Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
>>> Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
>>> Software Engineer D-26506 Norden http://www.norbit.de
>>> QGIS release manager (PSC) Germany IRC: jef on FreeNode
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>> iQIVAwUBVGMa+xBsJ9SQbsVUAQIbwRAAtuxd3KfMQtBWDm7kYg478kWW9baN4bEe
>>> oTTAst0RzohGrQy9ePN8NQdiWxOzEJih0VnSYoFr9F+6A5eZ2S6IrC6vUUpX0fh6
>>> 6oTqc0Cxf5GyzGhtMQA1uzLXCjXRLJkEGrylTpC1MvhVzsiRxSj7hCJdEEAzJOKt
>>> rybxf9Gtb7QSxAT2DNedmYPhfPpRzvcTB/JruDSjExHFxH7cH11iQpnhPv06+YVG
>>> 1MTQXIRuNQnMYhPj4MXqSbTzOhH/YcDfgf62k2RnKWhszzcLWIXBVz/m9Wl1gKXJ
>>> J0uNQYX9DKH1PbxR/HQ+GYxdX5/4NPEaM2T/mOGewWgVH0x79FX/3jFzvIhMrXJd
>>> 7yFFkWBlHpf8Ish0XoTaf5NbiH8Kha1DZsiXFwqh0tZOazuxRdoQC+WZ9Kg/0ESQ
>>> /jZe/eWP7/k7Kh9t2QOnJ7iqoqaK8hEdwHjC6MUece4CO8fmj+1SIS+xcb56ILK8
>>> dmP07G43mkWcnD7Dc25x6/bDB+hjCtMqkbDrBUtmpR4SJMHfJ7crIiQbiuslrHPe
>>> 56MFXud5dY8ykjY0Z0ELZ2XFPaenMLbAu0sUd1DbLi8vyeo8kY4oOeleuFp50Y+x
>>> hHy45bkc1hRlVNrHSHmZjhBJQ+sp0X/N4S7r6RlxkXsWkqx5Kly76lzMM4TVoDBk
>>> Tk8OTIGhSwk=
>>> =YvwM
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> _______________________________________________
>> Qgis-tr mailing list
>> Qgis-tr at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-tr
>>
>
> _______________________________________________
> Qgis-tr mailing list
> Qgis-tr at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-tr
More information about the Qgis-tr
mailing list