1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
%global _empty_manifest_terminate_build 0
Name: python-django-i18nfield
Version: 1.9.4
Release: 1
Summary: Store internationalized strings in Django models
License: Apache License 2.0
URL: https://github.com/raphaelm/django-i18nfield
Source0: https://mirrors.nju.edu.cn/pypi/web/packages/49/16/663d4708d7bd517b08d4e83426c01e8571fd9f7b09ef8602b50a01eca6aa/django-i18nfield-1.9.4.tar.gz
BuildArch: noarch
%description
This is yet another way to store multi-lingual content in Django_. In contrast to other options
like `django-hvad`_, `django-modeltranslation`_ or `django-parler`_ it does not require additonal
database tables and you can reconfigure the available languages without any changes to the database
schema. In constrast to `nece`_, it is not specific to PostgreSQL.
How does it work then? It stores JSON data into a ``TextField``. Yes, this is kinda dirty and violates
the `1NF`_. This makes it harder for non-django based programs to interact directly with your database
and is not perfectly efficient in terms of storage space.
It also lacks the ability to do useful lookups, searches and indices on internationalized fields.
If one of those things are important to you, **this project is not for you**, please choose one of the
ones that we linked above.
However if those limitations are fine for you, this provides you with a very lightweight, easy to use and
flexible solution. This approach has been in use in `pretix`_ for quite a while, so it has been tested in
production. The package contains not only the model fields, but also form fields and everything you need
to get them running.
%package -n python3-django-i18nfield
Summary: Store internationalized strings in Django models
Provides: python-django-i18nfield
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-django-i18nfield
This is yet another way to store multi-lingual content in Django_. In contrast to other options
like `django-hvad`_, `django-modeltranslation`_ or `django-parler`_ it does not require additonal
database tables and you can reconfigure the available languages without any changes to the database
schema. In constrast to `nece`_, it is not specific to PostgreSQL.
How does it work then? It stores JSON data into a ``TextField``. Yes, this is kinda dirty and violates
the `1NF`_. This makes it harder for non-django based programs to interact directly with your database
and is not perfectly efficient in terms of storage space.
It also lacks the ability to do useful lookups, searches and indices on internationalized fields.
If one of those things are important to you, **this project is not for you**, please choose one of the
ones that we linked above.
However if those limitations are fine for you, this provides you with a very lightweight, easy to use and
flexible solution. This approach has been in use in `pretix`_ for quite a while, so it has been tested in
production. The package contains not only the model fields, but also form fields and everything you need
to get them running.
%package help
Summary: Development documents and examples for django-i18nfield
Provides: python3-django-i18nfield-doc
%description help
This is yet another way to store multi-lingual content in Django_. In contrast to other options
like `django-hvad`_, `django-modeltranslation`_ or `django-parler`_ it does not require additonal
database tables and you can reconfigure the available languages without any changes to the database
schema. In constrast to `nece`_, it is not specific to PostgreSQL.
How does it work then? It stores JSON data into a ``TextField``. Yes, this is kinda dirty and violates
the `1NF`_. This makes it harder for non-django based programs to interact directly with your database
and is not perfectly efficient in terms of storage space.
It also lacks the ability to do useful lookups, searches and indices on internationalized fields.
If one of those things are important to you, **this project is not for you**, please choose one of the
ones that we linked above.
However if those limitations are fine for you, this provides you with a very lightweight, easy to use and
flexible solution. This approach has been in use in `pretix`_ for quite a while, so it has been tested in
production. The package contains not only the model fields, but also form fields and everything you need
to get them running.
%prep
%autosetup -n django-i18nfield-1.9.4
%build
%py3_build
%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .
%files -n python3-django-i18nfield -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 1.9.4-1
- Package Spec generated
|
